Replicación PostgreSQL

Constantemente nos enfrentamos a esto en la oficina, y la pregunta sigue surgiendo. ¿Cómo manejas la replicación PostgreSQL? Ni siquiera estoy hablando necesariamente de clústeres avanzados, solo lo mantengo simple con Master-Slave, Master-MultiSlave y Master-Master. Creo que configurarlo para MySQL suele ser bastante simple. La conmutación por error es sencilla, si no perfecta, especialmente por lo fácil que es configurarla. Hemos jugado con Slony, pero es demasiado práctico (los cambios de esquema requieren intervención, las nuevas bases de datos requieren intervención, etc.). PGPool2 fue bastante agradable, hasta que un nodo se cayó y no pudimos encontrar una forma elegante (aparte de derribar todo y volver a sembrar el nodo caído) para volver a sincronizar la replicación. Básicamente, esto es lo que normalmente busco:

• Configuración fácil (me conformaré con una configuración difícil, pero fácil de expandir)
• Conmutación por error simplista
• Recuperar un nodo caído solo requiere tiempo (es decir, como mysql. El servidor se cae, lo activa y espera que la replicación se ponga al día)
• Los cambios de esquema no rompen la replicación
• Agregar una nueva base de datos al servidor es perfecto (es decir, como mysql, puede replicar un servidor de base de datos completo, por lo que se crea una nueva base de datos en el maestro, que se propaga automáticamente al esclavo)

MySQL maneja la mayoría de estos bastante bien, pero tengo cierta afición por PostgreSQL. Además, tenemos algunas situaciones en las que es nuestra única opción, y nos gustaría agregar replicación a la mezcla. ¿Qué estás usando actualmente y cómo te sientes acerca de tu solución? Esto no es una publicación de MySQL versus PostgreSQL, lo prometo, porque eso no es lo que estoy tratando de comenzar. :)

Respuesta corta: todavía no existe tal solución para PostgreSQL si necesita esclavos de solo lectura en línea.

Actualmente hay dos proyectos de desarrollo importantes en curso en esta área que se incluyen en PostgreSQL 9.0 (Primavera / Verano 2010), a saber:

• Replicación Sincrónica:

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

• Leer solo esclavos en espera activa:

http://wiki.postgresql.org/wiki/Hot_Standby

que en combinación apuntan a lograr la facilidad de uso de la replicación de estilo MySQL menos los errores / problemas que MySQL tiene más la confiabilidad que los usuarios conocen de PostgreSQL.

Todo esto fue iniciado por un manifiesto del equipo central de PostgreSQL en 2008:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

Las soluciones de replicación de PostgreSQL hasta el día de hoy con la mayor base de usuarios son Slony-I (más costoso para las escrituras, hace que los cambios de esquema sean fiddly), WAL shipping / walmgr (Slaves no se pueden usar en línea) y pgQ / londiste de Skype / Skytools ( más herramientas / bloques de construcción que una solución terminada).

He escrito algunas cosas sobre Log Shipping, walmgr y Slony-I, mira

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 para obtener más información.

Y para lanzar otra solución al ring: rubyrep.

Para comparar con sus requisitos:

• Configuración fácil
  Sí, ese es realmente el enfoque principal de rubyrep.
• Conmutación por error simplista
  Sí. De hecho, rubyrep realiza la replicación maestro-maestro: para realizar la conmutación por error, no es necesaria ninguna acción. Simplemente comience a usar la otra base de datos.
• Los cambios de esquema no rompen la replicación
  Sí.
  Para los cambios de clave no primarios, la replicación ni siquiera tiene que detenerse (pero asegúrese de que el esquema sea cambios en ambos lados al mismo tiempo)
  Para agregar / eliminar tablas, simplemente reinicie el demonio de replicación. Solo cambiar la columna de clave principal de una tabla requiere un poco de esfuerzo.
• Agregar una nueva base de datos al servidor es perfecto (es decir, como mysql, puede replicar un servidor DB completo, por lo que se crea una nueva base de datos en el maestro, se propaga automáticamente al esclavo)
  Esto solo se admite de forma limitada: cada rubyrep El programa de instalación replica solo una base de datos a la vez. (Pero es muy fácil configurar la replicación para más de una base de datos).

No mencionó tener un esclavo de lectura activo como requisito, por lo que propondré usar Heartbeat con almacenamiento compartido o DRBD. Simplemente hace lo correcto y la administración es muy sencilla. Es el equivalente de Linux de los clústeres más antiguos de Microsoft SQL Server. Un nodo está activo y el otro nodo es pasivo mientras los datos se comparten entre los dos. No tiene que preocuparse por la replicación basada en SQL porque todo se maneja más abajo en el nivel de bloque.

En serio, es de lejos la mejor solución si no necesitas esclavos leídos. Lo mejor del archivo WAL fue en el mejor de los casos y debe configurar todo nuevamente si alguna vez interrumpe el proceso de envío para reiniciar el servidor. Slony y Londoniste no cortan la mostaza. Si desea permanecer en el árbol fuente principal y no comercializar, Heartbeat es su mejor opción.

Según sus requisitos, parece que PITR es la forma más fácil de resolver su problema:

Copia de seguridad en línea y recuperación en un punto en el tiempo (PITR)

No dijo que necesita consultar el servidor esclavo, por lo que PITR podría ser justo.

Es parte estándar de PostgreSQL de la versión 8.0, por lo que probablemente ya tenga todo lo necesario para ponerlo en funcionamiento.

Si encuentra instrucciones demasiado detalladas, eche un vistazo a SkyTools WalMgr, que hará que el proceso de creación / conmutación por error a la tarea de comando único de datos en espera activa .

Para escenarios de replicación más complejos, tuve una buena experiencia con Slony-1, pero PostgreSQL tiene muchas buenas opciones de replicación / HA disponibles.

Si desea una replicación asincrónica de maestro / esclavo, considere Londiste (parte del paquete skytools de Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

Es fácil de instalar, agregar un nuevo DB es fácil, la replicación simplemente "se pone al día".

Sin embargo, la conmutación por error no está integrada. Deberá cambiar las cadenas de conexión de su aplicación u ofuscar la conexión de la base de datos detrás de otra capa de software.

Algunos cambios de esquema son fáciles. Otros son más difíciles. Depende de su aplicación. Se supone que la próxima versión de skytools (ver 3.0) maneja DDL e incluye facilidades para facilitar la conmutación por error.

Nos mudamos a Londiste después de encontrar a Slony demasiado doloroso para usar.

Vea una discusión aquí, tal vez eso pueda ayudar:

http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

y

Competidores de Bucardo Version One, que se encuentran más abajo en la página:

http://www.planetpostgresql.org/

Realmente no hay formas gratuitas / de código abierto para proporcionar lo que está buscando. Si desea algo tan llave en mano, busque varias soluciones de replicación comercial de terceros.

Ahora, es posible ordenar su propia replicación con Postgres usando el envío de registro de encabezado de escritura (WAL):

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

Aquí es básicamente donde puede poner un nodo secundario en modo de recuperación continua e importar registros de transacciones en él cada {pequeño intervalo}. La configuración de Postgres tiene "apéndices" para permitirle hacer ciertas cosas cuando un Postgres cuando se completa un WAL y no, y eso es en lo que se basa esa configuración: utilizar esos "apéndices".

Sin embargo, eso no le permite hacer replicación maestro-maestro y / o circular.

En cualquier caso, definitivamente funciona por error, pero no lo llamaría "configuración fácil", "conmutación por error simplista", "sin interrupciones", ni nada de eso.

Excepto para 'agregar una nueva base de datos', puedes probar Mammoth Replicator ( https://projects.commandprompt.com/public/replicator ). Es de código abierto, fácil de configurar y admite conmutación por error. Las principales limitaciones son la base de datos única y la imposibilidad de replicar los cambios DDL, ambos están en la lista TODO.

Postgres-R parecía prometedor, pero no sé si el proyecto todavía está vivo.

Actualmente estoy mirando el replicador de tungsteno, todavía estoy lejos de cualquier conclusión definitiva, pero probablemente valga la pena echarle un vistazo.

www.continuent.com