{"id":93878,"date":"2020-09-10T19:42:02","date_gmt":"2020-09-10T17:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie"},"modified":"2020-09-10T19:42:02","modified_gmt":"2020-09-10T17:42:02","slug":"kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"\u00bfC\u00f3mo integrar PostgreSQL 'libre' en un entorno empresarial exigente?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Muchos conocen la base de datos PostgreSQL, que ha demostrado ser eficaz en instalaciones peque\u00f1as. Sin embargo, la tendencia hacia el uso de software de c\u00f3digo abierto se ha vuelto cada vez m\u00e1s evidente, incluso en grandes empresas y requisitos empresariales. En este art\u00edculo, explicaremos c\u00f3mo integrar Postgres en un entorno corporativo y compartiremos la experiencia de crear un sistema de copias de seguridad (SRK) para esta base de datos utilizando el sistema de copias de seguridad Commvault como ejemplo. <\/p>\n

\"\u00bfC\u00f3mo
\nPostgreSQL ya ha demostrado su val\u00eda: la base de datos funciona de maravilla, es utilizada por empresas digitales de renombre como Alibaba y TripAdvisor, y la ausencia de costos de licencia la convierte en una alternativa atractiva a gigantes como MS SQL o Oracle DB. Sin embargo, en cuanto comenzamos a pensar en PostgreSQL dentro del panorama empresarial, nos encontramos r\u00e1pidamente con exigencias estrictas: \u00ab\u00bfQu\u00e9 hay de la alta disponibilidad de la configuraci\u00f3n? \u00bfla recuperaci\u00f3n ante desastres? \u00bfd\u00f3nde est\u00e1 la supervisi\u00f3n integral? \u00bfy la copia de seguridad automatizada? \u00bfel uso de bibliotecas de cintas tanto directamente como en almacenamiento secundario?\u00bb
\n<\/a><\/noindex>
\n\"\u00bfC\u00f3mo
\nPor un lado, PostgreSQL no cuenta con herramientas de copia de seguridad integradas como las que tienen las \u00abgrandes\u00bb bases de datos, como RMAN en Oracle DB o SAP Database Backup. Por otro lado, los proveedores de sistemas de copias de seguridad empresariales (Veeam, Veritas, Commvault), aunque admiten PostgreSQL, en realidad solo trabajan con configuraciones espec\u00edficas (generalmente independientes) y un conjunto de diversas limitaciones. <\/p>\n

Sistemas de copias de seguridad dise\u00f1ados espec\u00edficamente para PostgreSQL, como Barman, Wal-g, pg_probackup, son extremadamente populares en instalaciones peque\u00f1as de PostgreSQL o donde no son necesarias copias de seguridad pesadas de otros elementos del panorama de TI. Por ejemplo, adem\u00e1s de PostgreSQL, la infraestructura puede incluir sistemas f\u00edsicos y virtuales. servidores<\/a>, OpenShift, Oracle, MariaDB, Cassandra, etc. Todo esto se recomienda respaldar con una herramienta com\u00fan. Implementar una soluci\u00f3n separada exclusivamente para PostgreSQL es una mala idea: los datos se copiar\u00e1n a un disco y luego necesitar\u00e1n ser movidos a una cinta. Esta duplicaci\u00f3n de copias de seguridad aumenta el tiempo de respaldo y, lo que es m\u00e1s cr\u00edtico, el de recuperaci\u00f3n.<\/p>\n

En la soluci\u00f3n empresarial, la copia de seguridad de la instalaci\u00f3n se realiza con un n\u00famero determinado de nodos de un cl\u00faster dedicado. Por ejemplo, Commvault solo puede trabajar con un cl\u00faster de dos nodos, donde el Primary y el Secondary est\u00e1n estrictamente asignados a nodos espec\u00edficos. Adem\u00e1s, tiene sentido hacer copias de seguridad solo con el Primary, ya que hacer copias de seguridad desde el Secondary tiene sus limitaciones. Debido a las caracter\u00edsticas del SGBD, no se crea un volcado en el Secondary, por lo que solo queda la posibilidad de una copia de seguridad de archivos.<\/p>\n

Para reducir el riesgo de tiempo de inactividad, al crear un sistema de alta disponibilidad se forma una configuraci\u00f3n de cl\u00faster 'viva', y el Primary puede migrar gradualmente entre diferentes servidores. Por ejemplo, el software Patroni inicia autom\u00e1ticamente el Primary en un nodo seleccionado aleatoriamente del cl\u00faster. El SRK no tiene forma de rastrear esto 'de f\u00e1brica', y si la configuraci\u00f3n cambia, los procesos se rompen. Es decir, la implementaci\u00f3n de la gesti\u00f3n externa interfiere con el funcionamiento eficaz del SRK, porque el servidor controlador simplemente no comprende de d\u00f3nde y qu\u00e9 datos necesita copiar.<\/p>\n

Otro problema es la implementaci\u00f3n de la copia de seguridad en Postgres. Es posible a trav\u00e9s de un volcado, y en bases peque\u00f1as esto funciona. Pero en bases de datos grandes, el volcado toma mucho tiempo, requiere muchos recursos y puede causar fallos en la instancia de la base de datos.<\/p>\n

La copia de seguridad de archivos soluciona la situaci\u00f3n, pero en bases grandes se vuelve lenta, ya que funciona en modo de un solo hilo. Adem\u00e1s, los proveedores tienen una serie de limitaciones adicionales. No se puede utilizar simult\u00e1neamente la copia de seguridad de archivos y la copia de seguridad de volcado, y a veces no se admite la deduplicaci\u00f3n. Hay muchos problemas, y a menudo es m\u00e1s f\u00e1cil elegir una base de datos cara, pero confiable, en lugar de Postgres.<\/p>\n

\u00a1No hay marcha atr\u00e1s! \u00a1Detr\u00e1s est\u00e1 Mosc\u00fa para los desarrolladores!<\/h2>\n

\nSin embargo, recientemente nuestro equipo se enfrent\u00f3 a un desaf\u00edo complicado: en el proyecto de creaci\u00f3n del AIS OSAGO 2.0, donde est\u00e1bamos desarrollando la infraestructura de TI, los desarrolladores eligieron PostgreSQL para el nuevo sistema. <\/p>\n

Para los grandes desarrolladores de software, es mucho m\u00e1s f\u00e1cil utilizar soluciones de c\u00f3digo abierto 'de moda'. En la plantilla de Facebook hay suficientes especialistas que mantienen el funcionamiento de este SGBD. Y en el caso de RSA, todas las tareas del 'segundo d\u00eda' reca\u00edan sobre nosotros. Se nos requer\u00eda asegurar la alta disponibilidad, ensamblar el cl\u00faster y, por supuesto, establecer la copia de seguridad. La l\u00f3gica de acci\u00f3n era la siguiente: <\/p>\n