sql >> Base de Datos >  >> RDS >> PostgreSQL

Diferencia entre la replicación de secuencias y la replicación lógica

TL;RD :la replicación lógica envía cambios fila por fila, la replicación física envía cambios de bloque de disco. La replicación lógica es mejor para algunas tareas, la replicación física para otras.

Tenga en cuenta que en PostgreSQL 12 (actualizado en el momento de la actualización), la replicación lógica es estable y confiable, pero bastante limitada. Use la replicación física si está haciendo esta pregunta.

La replicación de transmisión puede ser replicación lógica. Todo es un poco complicado.

Envío WAL frente a transmisión

Hay dos formas principales de enviar datos del maestro a la réplica en PostgreSQL:

  • WAL-envío o archivo continuo , donde los archivos de registro de escritura anticipada individuales se copian desde pg_xlog por el archive_command corriendo en el maestro a alguna otra ubicación. Un restore_command configurado en el recovery.conf de la réplica se ejecuta en la réplica para obtener los archivos para que la réplica pueda reproducir el WAL.

    Esto es lo que se usa para la replicación de un punto en el tiempo (PITR), que se utiliza como método de copia de seguridad continua.

    No se requiere una conexión de red directa al servidor maestro. La replicación puede tener largas demoras, especialmente sin un archive_timeout establecer. El envío WAL no se puede utilizar para la replicación síncrona.

  • replicación de transmisión , donde cada cambio se envía a uno o más servidores de réplica directamente a través de una conexión TCP/IP a medida que sucede. Las réplicas deben tener una conexión de red directa que el maestro configuró en su recovery.conf 's primary_conninfo opción.

    La replicación de transmisión tiene poco o ningún retraso siempre que la réplica sea lo suficientemente rápida para mantenerse al día. Se puede utilizar para replicación síncrona . No puede usar la replicación de transmisión para PITR, por lo que no es muy útil para la copia de seguridad continua. Si coloca una tabla en el maestro, vaya, también se colocará en las réplicas.

Por lo tanto, los dos métodos tienen diferentes propósitos.

Streaming asíncrono vs sincrónico

Además de eso, hay sincrónico y asincrónico replicación de transmisión:

  • En replicación de transmisión asíncrona se permite que las réplicas se atrasen con respecto al maestro en el tiempo cuando el maestro es más rápido/más ocupado. Si el maestro falla, es posible que pierda datos que aún no se replicaron.

    Si la réplica asíncrona se queda muy atrás del maestro, el maestro podría descartar la información que necesita la réplica si max_wal_size (anteriormente se llamaba wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's del maestro pg_wal(was pg_xlog) podría llenarse y hacer que el maestro deje de funcionar hasta que se libere espacio en disco si max_wal_size es demasiado alto o se usa una ranura.

  • En replicación síncrona el maestro no termina de confirmar hasta que una réplica ha confirmado que recibió la transacción. Nunca perderá datos si el maestro falla y tiene que conmutar por error a una réplica. El maestro nunca desechará los datos que necesita la réplica ni llenará su xlog y se quedará sin espacio en el disco debido a los retrasos de la réplica. A cambio, puede hacer que el maestro se ralentice o incluso deje de funcionar si las réplicas tienen problemas, y siempre tiene un impacto en el rendimiento del maestro debido a la latencia de la red.

    Cuando hay varias réplicas, solo una es sincrónica a la vez. Ver synchronous_standby_names .

No puede tener un envío de registros síncrono.

De hecho, puede combinar el envío de registros y la replicación asíncrona para evitar tener que volver a crear una réplica si se retrasa demasiado, sin correr el riesgo de afectar al maestro. Esta es una configuración ideal para muchas implementaciones, combinada con la supervisión de qué tan lejos está la réplica del maestro para garantizar que esté dentro de los límites aceptables de recuperación ante desastres.

Lógico vs físico

Además de eso tenemos lógico vs físico replicación de transmisión, como se introdujo en PostgreSQL 9.4:

  • En replicación de transmisión física los cambios se envían casi a nivel de bloque de disco, como "en el desplazamiento 14 de la página 18 del disco de la relación 12311, se escribió una tupla con valor hexadecimal 0x2342beef1222....".

    La replicación física envía todo :el contenido de cada base de datos en la instalación de PostgreSQL, todas las tablas en cada base de datos. Envía entradas de índice, envía todos los datos de la tabla nueva cuando VACUUM FULL , envía datos para transacciones que se revirtieron, etc. Por lo tanto, genera mucho "ruido" y envía muchos datos en exceso. También requiere que la réplica sea completamente idéntica, por lo que no puede hacer nada que requiera una transacción, como crear tablas temporales o no registradas. Consultar la réplica retrasa la replicación, por lo que las consultas largas en la réplica deben cancelarse.

A cambio, es simple y eficiente aplicar los cambios en la réplica, y la réplica es exactamente igual que el maestro. DDL se replica de forma transparente, como todo lo demás, por lo que no requiere un manejo especial. También puede transmitir grandes transacciones a medida que ocurren, por lo que hay poca demora entre la confirmación en el maestro y la confirmación en la réplica, incluso para grandes cambios.

La replicación física está madura, bien probada y ampliamente adoptada.

  • replicación de transmisión lógica , nuevo en 9.4, envía cambios a un nivel superior y de forma mucho más selectiva.

Solo replica una base de datos a la vez. Envía solo cambios de fila y solo para transacciones comprometidas, y no tiene que enviar datos vacíos, cambios de índice, etc. Puede enviar datos de manera selectiva solo para algunas tablas dentro de una base de datos. Esto hace que la replicación lógica mucho más eficiente en ancho de banda.

Operar a un nivel superior también significa que puede realizar transacciones en las bases de datos de réplica. Puede crear tablas temporales y no registradas. Incluso mesas normales, si quieres. Puede usar envoltorios de datos externos, vistas, crear funciones, lo que quiera. Tampoco es necesario cancelar las consultas si duran demasiado.

La replicación lógica también se puede usar para crear una replicación multimaestro en PostgreSQL, lo que no es posible con la replicación física.

Sin embargo, a cambio, no puede (actualmente) transmitir grandes transacciones a medida que ocurren. Tiene que esperar hasta que se comprometan. Por lo tanto, puede haber una gran demora entre la confirmación de una gran transacción en el maestro y la aplicación a la réplica.

Reproduce las transacciones estrictamente en orden de confirmación, por lo que las transacciones pequeñas y rápidas pueden quedarse atascadas detrás de una transacción grande y retrasarse bastante.

DDL no se maneja automáticamente. Debe mantener sincronizadas las definiciones de la tabla entre el maestro y la réplica, o la aplicación que usa la replicación lógica debe tener sus propias instalaciones para hacer esto. Puede ser complicado hacerlo bien.

El proceso de aplicación en sí mismo es más complicado que "escribir algunos bytes donde me lo indiquen". También requiere más recursos en la réplica que la réplica física.

Las implementaciones de replicación lógica actuales no están maduras ni son ampliamente adoptadas, o particularmente fáciles de usar.

Demasiadas opciones, dime qué hacer

Uf. Complicado, ¿eh? Y ni siquiera me he metido en los detalles de la replicación retrasada, las ranuras, max_wal_size , cronogramas, cómo funciona la promoción, Postgres-XL, BDR y multimaestro, etc.

Entonces, ¿qué deberías hacer? ?

No hay una única respuesta correcta. De lo contrario, PostgreSQL solo admitiría esa única forma. Pero hay algunos casos de uso comunes:

Para copia de seguridad y recuperación ante desastres usa pgbarman para hacer copias de seguridad básicas y retener WAL para usted, proporcionando una copia de seguridad continua fácil de administrar. Aún debe tomar pg_dump periódicos copias de seguridad como seguro extra.

Para alta disponibilidad sin riesgo de pérdida de datos utilice la replicación síncrona de transmisión.

Para alta disponibilidad con bajo riesgo de pérdida de datos y mejor rendimiento debe usar la replicación de transmisión asincrónica. Tenga habilitado el archivado WAL para respaldo o use una ranura de replicación. Controle qué tan lejos está la réplica del maestro usando herramientas externas como Icinga.

Referencias