¿Cómo se compara la replicación nativa de PostgreSQL con MySQL?
Sé que la replicación asincrónica ha sido compatible durante más tiempo que la sincronización, que es reciente. ¿Es síncrono confiable para ser utilizado en proyectos reales?
¿Cómo se compara la replicación nativa de PostgreSQL con MySQL?
Sé que la replicación asincrónica ha sido compatible durante más tiempo que la sincronización, que es reciente. ¿Es síncrono confiable para ser utilizado en proyectos reales?
Respuestas:
Sí, está listo para la producción y es ampliamente utilizado. Los seguidores de Heroku se basan, por ejemplo, en la replicación asíncrona incorporada de PostgreSQL, al igual que las réplicas de lectura y en espera de AWS RDS. La replicación de transmisión se usa casi universalmente con PostgreSQL.
La configuración de la replicación no es exactamente encantadora, pero las herramientas como repmgr ayudan un poco con eso, y está mejorando lentamente con cada versión principal. La capacidad de pg_basebackup para tomar una copia del sistema usando la replicación de transmisión (y hacerlo desde otro modo de espera) es de gran ayuda.
En general, una característica simplemente no se lanzará en PostgreSQL hasta que esté lista para producción. Los errores ocurren, como en cualquier software, pero generalmente se solucionan poco después de ser identificados. Las nuevas características realmente importantes a veces tienen errores y problemas descubiertos después de la versión .0, pero si es así, solucionarlos es una alta prioridad; los errores no solo se dejan.
No conozco ningún problema serio con la replicación de transmisión (sincronización o asíncrona) ni he visto ningún informe durante bastante tiempo. Eran menos estables que el estándar habitual de Pg en las versiones .0 de las versiones principales en las que se introdujeron, pero ambas maduraron rápidamente y están completamente listas para la producción.
(Actualización: hubo un error específico en la nueva versión 9.3 anterior a 9.3.4 que causó problemas de replicación en algunos casos; los usuarios de 9.3 deberían actualizar a 9.3.4 de inmediato. Las versiones anteriores no se ven afectadas).
La única advertencia que quiero mencionar es un detalle menor con replicación síncrona: si confirma en el maestro, cancele la consulta después de que confirme mientras espera que la réplica confirme, se trata como confirmada en el maestro incluso antes de que se replique. Obtiene el mismo efecto reiniciando el maestro mientras espera que la réplica responda. En la práctica, esto es irrelevante, pero es el único problema en el que puedo pensar.
La replicación nativa de Pg es bastante diferente a la de MySQL.
MySQL usa la replicación lógica donde envía los cambios lógicos realizados a los datos de la tabla, la estructura de la tabla, etc., y la réplica aplica esos cambios.
La replicación de PostgreSQL es de nivel inferior (en 9.5 y versiones inferiores; las versiones futuras también pueden agregar replicación lógica). Envía los bloques que cambiaron en las tablas. Es más simple, más fácil de corregir, e impone una carga menor en el servidor de réplica, pero consume más ancho de banda de red y requiere más almacenamiento en el maestro para contener los cambios aún no replicados. Se configura mejor para usar la replicación de transmisión con el respaldo de archivado WAL, lo que hace que sea más complejo de configurar que MySQL. Replica los cambios de bajo nivel, como la actividad de VACÍO, no solo los cambios de tupla, manteniendo el estado en el disco de la réplica igual al del maestro. Es incapaz de replicar solo una base de datos; todo el sistema debe ser replicado, lo que puede ser frustrante si tiene una base de datos grande, de alta rotación y sin importancia, y una base de datos pequeña, de baja rotación y vital.
Con todo, depende de lo que quieras hacer con él.
Veo la replicación de PostgreSQL como considerablemente mejor para las réplicas utilizadas para copias de seguridad, alta disponibilidad y recuperación ante desastres. Particularmente cuando se combina con el punto de recuperación de tiempo (PITR) .
Por otro lado, no es tan bueno para las réplicas de informes de solo lectura porque la necesidad de retrasar la aplicación de datos replicados mientras se ejecutan transacciones largas significa que debe dejar que cancele consultas de ejecución muy larga o quedarse muy atrás del maestro, consumiendo más espacio en disco en el maestro y lo obliga a trabajar más duro para mantenerse al día.
Hay trabajo en curso para habilitar la replicación lógica en PostgreSQL , donde los cambios lógicos en la estructura de la tabla, el contenido de la tabla, etc. se replican, en lugar de su estado en el disco. El diseño del catálogo de Pg y el soporte para todo lo definido por el usuario hacen que esta tarea sea bastante compleja. Algunas de las bases se han implementado para 9.4, pero es poco probable que la replicación lógica completa sea utilizable antes de 9.6 o posterior.