Pregunta Replicación PostgreSQL


Constantemente bateamos esto en la oficina, y la pregunta sigue surgiendo. ¿Cómo lidias con la replicación de PostgreSQL? Ni siquiera estoy hablando necesariamente de clusters avanzados, simplemente manteniéndolo simple con Master-Slave, Master-MultiSlave y Master-Master. Encuentro que configurarlo para MySQL es típicamente bastante simple. La conmutación por error es sencilla, si no perfecta, especialmente por lo fácil que es configurar. Hemos jugado con Slony, pero es un poco demasiado práctico (los cambios de esquema requieren intervención, las nuevas bases de datos requieren intervención, etc.). PGPool2 fue bastante bueno, hasta que un nodo se apagó y no pudimos encontrar una forma elegante (que no fuera bajar todo y reiniciar 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)
  • Failover simplista
  • Devolver un nodo caído solo requiere tiempo (es decir, como mysql. El servidor se desactiva, lo recuperas y esperas a que la replicación se ponga al día)
  • Los cambios de esquema no rompen la replicación
  • La adición de una nueva base de datos al servidor es perfecta (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)

MySQL maneja la mayoría de estos bastante bien, pero tengo cierto cariño 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á utilizando actualmente y cómo se siente con respecto a su solución? Esto no es una publicación de MySQL versus PostgreSQL, lo prometo, porque no es lo que estoy tratando de comenzar. :)


45
2018-05-22 06:22


origen


Estoy interesado en la respuesta a esto. Desde el fondo de MySQL, las opciones de replicación para PSQL son agrícolas, por decir lo menos. - Dave Cheney
Sí, hasta ahora todas las opciones con las que he jugado han tenido inconvenientes significativos. Espero que me esté perdiendo algo obvio .. pero no creo que lo esté - f4nt
Sospecho que no hay nada más, pero estoy ansioso por que alguien me demuestre que estoy equivocado - Vinko Vrsalovic
Por cierto, ¿has probado pgsql-general@postgresql.org? - Vinko Vrsalovic


Respuestas:


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

Actualmente hay dos grandes proyectos de desarrollo 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:

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

que, en combinación, tienen como objetivo lograr la facilidad de uso de la replicación estilo MySQL sin los errores / problemas que MySQL tiene, además de 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 base de usuarios más grande son Slony-I (más caras para escrituras, modifica los cambios de esquema), WAL shipping / walmgr (Slaves no se puede 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 en Log Shipping, walmgr y Slony-I, vea

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


9
2018-05-29 15:47



La replicación sincrónica + Hot Standby ahora están disponibles - ver wiki.postgresql.org/wiki/… Para un buen resumen de las técnicas disponibles. - David Fraser


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

Para comparar con sus requerimientos:

  • Configuración fácil
    Sí, ese es realmente el enfoque principal de rubyrep.
  • Failover simplista
    Sí. De hecho, rubyrep realiza la replicación maestro-maestro: para fallar, no es necesario realizar ninguna acción. Simplemente comienza a usar la otra base de datos.
  • Los cambios de esquema no rompen la replicación
    Sí.
    Para los cambios de claves no primarias, 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.
  • La adición de una nueva base de datos al servidor es perfecta (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 configuración rubyrep 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).

5
2017-07-01 06:41





No mencionó tener un esclavo de lectura activa como requisito, así que propondré usar Heartbeat con almacenamiento compartido o DRBD. Simplemente hace lo correcto y la administración es muy fácil. Es el equivalente en Linux de un clúster de Microsoft SQL Server anterior. 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 por mucho la mejor solución si no necesitas leer esclavos. Lo mejor del archivo WAL era muy bueno y debes configurarlo todo de nuevo si alguna vez interrumpes el proceso de envío para un reinicio del servidor. Slony y London no cortan la mostaza. Si desea permanecer en el árbol de fuentes principal y no ir a un comercial, Heartbeat es su mejor apuesta.


4
2018-05-27 18:02





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 de un punto en el tiempo (PITR)

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

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

Si encuentra instrucciones muy detalladas, eche un vistazo a SkyTools WalMgr lo que hará que el proceso de creación / conmutación por error a la tarea de comando único de datos de 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.


2
2018-05-22 13:25



y esas opciones son ...? - Dave Cheney
... listado en la publicación del blog blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html referenciado en una de las respuestas ... - dpavlin


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

Es fácil de instalar, agregar una nueva base de datos es fácil, la replicación simplemente "se pone al día".

Sin embargo, la conmutación por error no está integrada. Necesitará cambiar las cadenas de conexión de su aplicación u ofuscar la conexión DB 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) debe manejar DDL e incluir instalaciones para facilitar la conmutación por error.

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


2
2018-05-27 17:53





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

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

y

Competidores a la versión uno de Bucardo, que se encuentra más abajo en la página:

http://www.planetpostgresql.org/


1
2018-05-22 09:09





Realmente no hay ninguna forma libre / de código abierto para proporcionar lo que estás buscando. Si desea algo que sea tan llave en mano, consulte varias soluciones de replicación comercial de terceros.

Ahora es es posible ordenar su propia replicación con Postgres usando el envío del 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 "stubs" que le permiten hacer ciertas cosas cuando se completa un Postgres cuando se completa un WAL y por lo tanto no, y en eso se basa esa configuración: utilizar esos "stubs".

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

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


1
2018-05-27 10:10



esta respuesta es un duplicado de la sugerencia de PITR, ya que PITR usa WAL :-) - dpavlin


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


1
2018-05-29 18:18





Postgres-R Parecía prometedor, pero no sé si el proyecto sigue vivo.


0
2018-05-26 19:28





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

www.continuent.com


0
2018-05-26 18:30