Replicación de PostgreSQL: una guía completa

Como le dirá cualquier propietario de un sitio, la pérdida de datos y el tiempo de inactividad, incluso en dosis mínimas, pueden ser catastróficos. Pueden golpear a los que no están preparados en cualquier momento, lo que reduce la productividad, la accesibilidad y la confianza en el producto.

Para proteger la integridad de su sitio, es vital crear medidas de seguridad contra la posibilidad de tiempo de inactividad o pérdida de datos.

Ahí es donde entra la replicación de datos.
Como cualquier propietario de un sitio le dirá que la pérdida de datos y el tiempo de inactividad, incluso en dosis mínimas, pueden ser catastróficos. Ingrese, replicación de datos Haga clic para twittear
La replicación de datos es un proceso de copia de seguridad automatizado en el que sus datos se copian repetidamente desde su base de datos principal a otra ubicación remota para su custodia. Es una tecnología integral para cualquier sitio o aplicación que ejecute un servidor de base de datos. También puede aprovechar la base de datos replicada para procesar SQL de solo lectura, lo que permite ejecutar más procesos dentro del sistema.

La configuración de la replicación entre dos bases de datos ofrece tolerancia a fallas contra percances inesperados. Se considera que es la mejor estrategia para lograr una alta disponibilidad durante los desastres.

En este artículo, nos sumergiremos en las diferentes estrategias que pueden implementar los desarrolladores de back-end para una replicación de PostgreSQL perfecta.

¿Qué es la replicación de PostgreSQL?

La replicación de PostgreSQL se define como el proceso de copiar datos de un servidor de base de datos de PostgreSQL a otro servidor. El servidor de la base de datos de origen también se conoce como el servidor "primario", mientras que el servidor de la base de datos que recibe los datos copiados se conoce como el servidor "réplica".

La base de datos de PostgreSQL sigue un modelo de replicación sencillo, donde todas las escrituras van a un nodo principal. Luego, el nodo principal puede aplicar estos cambios y transmitirlos a los nodos secundarios.

¿Qué es la conmutación por error automática?

Una vez que se ha configurado la replicación de transmisión física en PostgreSQL, se puede realizar la conmutación por error si falla el servidor principal de la base de datos. La conmutación por error se usa para definir el proceso de recuperación, que puede llevar un tiempo, ya que no proporciona herramientas integradas para detectar fallas en el servidor.

No tiene que depender de PostgreSQL para la conmutación por error. Hay herramientas dedicadas que permiten la conmutación automática por error y el cambio automático al modo de espera, lo que reduce el tiempo de inactividad de la base de datos.

Al configurar la replicación de conmutación por error, casi garantiza una alta disponibilidad al asegurarse de que los servidores de reserva estén disponibles si el servidor principal colapsa alguna vez.

Beneficios de usar la replicación de PostgreSQL

Estos son algunos de los beneficios clave de aprovechar la replicación de PostgreSQL:

• Migración de datos : puede aprovechar la replicación de PostgreSQL para la migración de datos mediante un cambio de hardware del servidor de la base de datos o mediante la implementación del sistema.
• Tolerancia a fallas : si el servidor principal falla, el servidor en espera puede actuar como un servidor porque los datos contenidos para los servidores principal y en espera son los mismos.
• Rendimiento del procesamiento transaccional en línea (OLTP) : puede mejorar el tiempo de procesamiento de transacciones y el tiempo de consulta de un sistema OLTP eliminando la carga de consultas de informes. El tiempo de procesamiento de transacciones es el tiempo que tarda en ejecutarse una consulta determinada antes de que finalice una transacción.
• Pruebas del sistema en paralelo : al actualizar un nuevo sistema, debe asegurarse de que el sistema funcione bien con los datos existentes, de ahí la necesidad de probar con una copia de la base de datos de producción antes de la implementación.

Cómo funciona la replicación de PostgreSQL

En general, la gente cree que cuando está incursionando con una arquitectura primaria y secundaria, solo hay una forma de configurar las copias de seguridad y la replicación, pero las implementaciones de PostgreSQL siguen uno de los siguientes tres enfoques:

1. Replicación a nivel de volumen para replicar en la capa de almacenamiento desde el nodo principal al secundario, seguido de una copia de seguridad en el almacenamiento S3/blob.
2. Replicación de transmisión de PostgreSQL para replicar datos del nodo principal al secundario, seguido de una copia de seguridad en el almacenamiento S3/blob.
3. Realización de copias de seguridad incrementales desde el nodo principal a S3 mientras se reconstruye un nuevo nodo secundario desde S3. Cuando el nodo secundario está cerca del principal, puede comenzar a transmitir desde el nodo principal.

Enfoque 1: Streaming

La replicación de transmisión de PostgreSQL, también conocida como replicación WAL, se puede configurar sin problemas después de instalar PostgreSQL en todos los servidores. Este enfoque de la replicación se basa en mover los archivos WAL de la base de datos principal a la de destino.

Puede implementar la replicación de transmisión de PostgreSQL mediante una configuración primaria-secundaria. El servidor primario es la instancia principal que maneja la base de datos primaria y todas sus operaciones. El servidor secundario actúa como instancia complementaria y ejecuta todos los cambios realizados en la base de datos principal en sí mismo, generando una copia idéntica en el proceso. El principal es el servidor de lectura/escritura, mientras que el servidor secundario es simplemente de solo lectura.

Para este enfoque, debe configurar tanto el nodo principal como el nodo en espera. Las siguientes secciones aclararán los pasos necesarios para configurarlos con facilidad.

Configuración del nodo principal

Puede configurar el nodo principal para la replicación de transmisión realizando los siguientes pasos:

Paso 1: inicializar la base de datos

Para inicializar la base de datos, puede aprovechar el comando de la initidb utility . A continuación, puede crear un nuevo usuario con privilegios de replicación utilizando el siguiente comando:

 CREATE USER REPLICATION LOGIN ENCRYPTED PASSWORD '';

El usuario deberá proporcionar una contraseña y un nombre de usuario para la consulta dada. La palabra clave de replicación se utiliza para otorgar al usuario los privilegios necesarios. Una consulta de ejemplo se vería así:

 CREATE USER rep_user REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_pass'

Paso 2: configurar las propiedades de transmisión

A continuación, puede configurar las propiedades de transmisión con el archivo de configuración de PostgreSQL ( postgresql.conf ) que se puede modificar de la siguiente manera:

 wal_level = logical wal_log_hints = on max_wal_senders = 8 max_wal_size = 1GB hot_standby = on

Aquí hay un poco de información sobre los parámetros utilizados en el fragmento anterior:

• wal_log_hints : este parámetro es necesario para la pg_rewind que resulta útil cuando el servidor en espera no está sincronizado con el servidor principal.
• wal_level : puede usar este parámetro para habilitar la replicación de transmisión de PostgreSQL, con valores posibles que incluyen minimal , replica o logical .
• max_wal_size : Esto se puede usar para especificar el tamaño de los archivos WAL que se pueden retener en los archivos de registro.
• hot_standby : puede aprovechar este parámetro para una conexión de lectura con el secundario cuando está activado.
• max_wal_senders : puede usar max_wal_senders para especificar la cantidad máxima de conexiones simultáneas que se pueden establecer con los servidores en espera.

Paso 3: Crear nueva entrada

Después de modificar los parámetros en el archivo postgresql.conf, una nueva entrada de replicación en el archivo pg_hba.conf puede permitir que los servidores establezcan una conexión entre sí para la replicación.

Por lo general, puede encontrar este archivo en el directorio de datos de PostgreSQL. Puede usar el siguiente fragmento de código para lo mismo:

 host replication rep_user IPaddress md5

Una vez que se ejecuta el fragmento de código, el servidor principal permite que un usuario llamado rep_user se conecte y actúe como servidor en espera utilizando la IP especificada para la replicación. Por ejemplo:

 host replication rep_user 192.168.0.22/32 md5

Configuración del nodo en espera

Para configurar el nodo en espera para la replicación de transmisión, siga estos pasos:

Paso 1: Copia de seguridad del nodo principal

Para configurar el nodo en espera, aproveche la utilidad pg_basebackup para generar una copia de seguridad del nodo principal. Esto servirá como punto de partida para el nodo en espera. Puede utilizar esta utilidad con la siguiente sintaxis:

 pg_basebackp -D -h -X stream -c fast -U rep_user -W

Los parámetros utilizados en la sintaxis mencionada anteriormente son los siguientes:

• -h : puede usar esto para mencionar el host principal.
• -D : este parámetro indica el directorio en el que está trabajando actualmente.
• -C : Puede usar esto para establecer los puntos de control.
• -X : este parámetro se puede usar para incluir los archivos de registro de transacciones necesarios.
• -W : puede usar este parámetro para solicitar al usuario una contraseña antes de vincularse a la base de datos.

Paso 2: configurar el archivo de configuración de replicación

A continuación, debe verificar si existe el archivo de configuración de replicación. Si no es así, puede generar el archivo de configuración de replicación como recovery.conf.

Debe crear este archivo en el directorio de datos de la instalación de PostgreSQL. Puede generarlo automáticamente usando la opción -R dentro de la utilidad pg_basebackup .

El archivo recovery.conf debe contener los siguientes comandos:

standby_mode = 'encendido'

primary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=”host_name”'

recovery_target_timeline = 'más reciente'

Los parámetros utilizados en los comandos antes mencionados son los siguientes:

• primary_conninfo : puede usar esto para establecer una conexión entre los servidores principal y secundario aprovechando una cadena de conexión.
• standby_mode : este parámetro puede hacer que el servidor principal se inicie como modo de espera cuando se enciende.
• recovery_target_timeline : puede usar esto para establecer el tiempo de recuperación.

Para configurar una conexión, debe proporcionar el nombre de usuario, la dirección IP y la contraseña como valores para el parámetro primary_conninfo. Por ejemplo:

 primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'

Paso 3: reiniciar el servidor secundario

Finalmente, puede reiniciar el servidor secundario para completar el proceso de configuración.

Sin embargo, la replicación de transmisión presenta varios desafíos, como:

• Varios clientes PostgreSQL (escritos en diferentes lenguajes de programación) conversan con un solo punto final. Cuando el nodo principal falla, estos clientes seguirán intentando con el mismo nombre de IP o DNS. Esto hace que la conmutación por error sea visible para la aplicación.
• La replicación de PostgreSQL no viene con conmutación por error ni supervisión integradas. Cuando el nodo principal falla, debe promocionar un secundario para que sea el nuevo principal. Esta promoción debe ejecutarse de forma que los clientes escriban solo en un nodo principal y no observen incoherencias en los datos.
• PostgreSQL replica todo su estado. Cuando necesita desarrollar un nuevo nodo secundario, el secundario necesita recapitular todo el historial de cambio de estado del nodo principal, lo que consume muchos recursos y hace que sea costoso eliminar nodos en la cabeza y crear otros nuevos.

Enfoque 2: dispositivo de bloque replicado

El enfoque de dispositivo de bloque replicado depende de la duplicación de disco (también conocida como replicación de volumen). En este enfoque, los cambios se escriben en un volumen persistente que se refleja sincrónicamente en otro volumen.

El beneficio adicional de este enfoque es su compatibilidad y durabilidad de los datos en entornos de nube con todas las bases de datos relacionales, incluidas PostgreSQL, MySQL y SQL Server, por nombrar algunas.

Sin embargo, el enfoque de duplicación de disco para la replicación de PostgreSQL necesita que replique los datos de tabla y registro de WAL. Dado que cada escritura en la base de datos ahora debe pasar por la red de forma sincrónica, no puede permitirse perder un solo byte, ya que eso podría dejar su base de datos en un estado corrupto.

Este enfoque normalmente se aprovecha con Azure PostgreSQL y Amazon RDS.

Enfoque 3: WAL

WAL consta de archivos de segmento (16 MB por defecto). Cada segmento tiene uno o más registros. Un registro de secuencia de registro (LSN) es un puntero a un registro en WAL, que le permite saber la posición/ubicación donde se guardó el registro en el archivo de registro.

Un servidor en espera aprovecha los segmentos WAL, también conocidos como XLOGS en la terminología de PostgreSQL, para replicar continuamente los cambios de su servidor principal. Puede usar el registro de escritura anticipada para otorgar durabilidad y atomicidad en un DBMS mediante la serialización de fragmentos de datos de matriz de bytes (cada uno con un LSN único) en un almacenamiento estable antes de que se apliquen a una base de datos.

La aplicación de una mutación a una base de datos puede dar lugar a varias operaciones del sistema de archivos. Una pregunta pertinente que surge es cómo una base de datos puede asegurar la atomicidad en el caso de una falla del servidor debido a un corte de energía mientras estaba en medio de una actualización del sistema de archivos. Cuando se inicia una base de datos, comienza un proceso de inicio o reproducción que puede leer los segmentos WAL disponibles y compararlos con el LSN almacenado en cada página de datos (cada página de datos se marca con el LSN del último registro WAL que afecta la página).

Replicación basada en envío de registros (nivel de bloque)

La replicación de transmisión refina el proceso de envío de registros. A diferencia de esperar el cambio de WAL, los registros se envían a medida que se crean, lo que reduce el retraso de la replicación.

La replicación de transmisión también supera el envío de registros porque el servidor en espera se vincula con el servidor principal a través de la red al aprovechar un protocolo de replicación. El servidor principal puede enviar registros WAL directamente a través de esta conexión sin tener que depender de los scripts proporcionados por el usuario final.

Replicación basada en envío de registros (nivel de archivo)

El envío de registros se define como la copia de archivos de registro en otro servidor PostgreSQL para generar otro servidor en espera mediante la reproducción de archivos WAL. Este servidor está configurado para funcionar en modo de recuperación y su único propósito es aplicar cualquier archivo WAL nuevo a medida que aparecen.

Este servidor secundario se convierte en una copia de seguridad tibia del servidor principal de PostgreSQL. También se puede configurar para que sea una réplica de lectura, donde puede ofrecer consultas de solo lectura, también denominadas espera activa.

Archivo WAL continuo

La duplicación de archivos WAL a medida que se crean en cualquier ubicación que no sea el subdirectorio pg_wal para archivarlos se conoce como archivado WAL. PostgreSQL llamará a un script proporcionado por el usuario para archivar, cada vez que se cree un archivo WAL.

El script puede aprovechar el comando scp para duplicar el archivo en una o más ubicaciones, como un montaje NFS. Una vez archivados, los archivos del segmento WAL se pueden aprovechar para recuperar la base de datos en cualquier momento dado.

Otras configuraciones basadas en registros incluyen:

• Replicación sincrónica : antes de que se confirme cada transacción de replicación sincrónica, el servidor principal espera hasta que los servidores de reserva confirmen que recibieron los datos. El beneficio de esta configuración es que no habrá conflictos causados ​​por procesos de escritura paralelos.
• Replicación síncrona multimaestro : aquí, cada servidor puede aceptar solicitudes de escritura y los datos modificados se transmiten desde el servidor original a todos los demás servidores antes de que se confirme cada transacción. Aprovecha el protocolo 2PC y se adhiere a la regla de todo o nada.

Detalles del protocolo de transmisión WAL

Un proceso conocido como receptor WAL, que se ejecuta en el servidor en espera, aprovecha los detalles de conexión proporcionados en el parámetro primary_conninfo de recovery.conf y se conecta al servidor principal mediante una conexión TCP/IP.

Para iniciar la replicación de transmisión, la interfaz puede enviar el parámetro de replicación dentro del mensaje de inicio. Un valor booleano de verdadero, sí, 1 u ENCENDIDO permite que el backend sepa que debe pasar al modo walsender de replicación física.

El remitente WAL es otro proceso que se ejecuta en el servidor principal y está a cargo de enviar los registros WAL al servidor en espera a medida que se generan. El receptor WAL guarda los registros WAL en WAL como si fueran creados por la actividad del cliente de los clientes conectados localmente.

Una vez que los registros WAL llegan a los archivos del segmento WAL, el servidor en espera sigue reproduciendo constantemente el WAL para que el principal y el en espera estén actualizados.

Elementos de la replicación de PostgreSQL

En esta sección, obtendrá una comprensión más profunda de los modelos comúnmente utilizados (replicación de maestro único y maestro múltiple), tipos (replicación física y lógica) y modos (sincrónicos y asincrónicos) de la replicación de PostgreSQL.

Modelos de replicación de bases de datos PostgreSQL

La escalabilidad significa agregar más recursos/hardware a los nodos existentes para mejorar la capacidad de la base de datos para almacenar y procesar más datos, lo que se puede lograr horizontal y verticalmente. La replicación de PostgreSQL es un ejemplo de escalabilidad horizontal que es mucho más difícil de implementar que la escalabilidad vertical. Podemos lograr escalabilidad horizontal principalmente mediante replicación de maestro único (SMR) y replicación de maestro múltiple (MMR).

La replicación de maestro único permite que los datos se modifiquen solo en un solo nodo, y estas modificaciones se replican en uno o más nodos. Las tablas replicadas en la base de datos de réplica no pueden aceptar ningún cambio, excepto los del servidor principal. Incluso si lo hacen, los cambios no se replican en el servidor principal.

La mayoría de las veces, SMR es suficiente para la aplicación porque es menos complicado de configurar y administrar y no hay posibilidades de conflictos. La replicación de maestro único también es unidireccional, ya que los datos de replicación fluyen principalmente en una dirección, desde la base de datos primaria a la réplica.

En algunos casos, SMR solo puede no ser suficiente y es posible que deba implementar MMR. MMR permite que más de un nodo actúe como nodo principal. Los cambios en las filas de la tabla en más de una base de datos primaria designada se replican en sus tablas equivalentes en todas las demás bases de datos primarias. En este modelo, a menudo se emplean esquemas de resolución de conflictos para evitar problemas como claves primarias duplicadas.

Hay algunas ventajas de usar MMR, a saber:

• En caso de falla del host, otros hosts aún pueden brindar servicios de actualización e inserción.
• Los nodos principales se distribuyen en varias ubicaciones diferentes, por lo que la probabilidad de falla de todos los nodos principales es muy pequeña.
• Capacidad para emplear una red de área amplia (WAN) de bases de datos primarias que pueden estar geográficamente cerca de grupos de clientes y, sin embargo, mantener la coherencia de los datos en toda la red.

Sin embargo, la desventaja de implementar MMR es la complejidad y su dificultad para resolver conflictos.

Varias sucursales y aplicaciones brindan soluciones MMR ya que PostgreSQL no es compatible de forma nativa. Estas soluciones pueden ser de código abierto, gratuitas o de pago. Una de esas extensiones es la replicación bidireccional (BDR), que es asíncrona y se basa en la función de decodificación lógica de PostgreSQL.

Dado que la aplicación BDR reproduce transacciones en otros nodos, la operación de reproducción puede fallar si hay un conflicto entre la transacción que se aplica y la transacción confirmada en el nodo receptor.

Tipos de replicación de PostgreSQL

Hay dos tipos de replicación de PostgreSQL: replicación lógica y física.

Una simple operación lógica “initdb” llevaría a cabo la operación física de crear un directorio base para un clúster. Asimismo, una simple operación lógica “CREAR BASE DE DATOS” realizaría la operación física de crear un subdirectorio en el directorio base.

La replicación física generalmente trata con archivos y directorios. No sabe qué representan estos archivos y directorios. Estos métodos se utilizan para mantener una copia completa de todos los datos de un solo clúster, generalmente en otra máquina, y se realizan a nivel del sistema de archivos o del disco y usan direcciones de bloque exactas.

La replicación lógica es una forma de reproducir entidades de datos y sus modificaciones, en función de su identidad de replicación (generalmente una clave principal). A diferencia de la replicación física, trata con bases de datos, tablas y operaciones DML y se realiza a nivel de clúster de base de datos. Utiliza un modelo de publicación y suscripción donde uno o más suscriptores están suscritos a una o más publicaciones en un nodo de publicación .

El proceso de replicación comienza tomando una instantánea de los datos en la base de datos del editor y luego copiándola al suscriptor. Los suscriptores extraen datos de las publicaciones a las que se suscriben y pueden volver a publicar los datos más tarde para permitir la replicación en cascada o configuraciones más complejas. El suscriptor aplica los datos en el mismo orden que el editor, de modo que se garantiza la consistencia transaccional para las publicaciones dentro de una sola suscripción, lo que también se conoce como replicación transaccional.

Los casos de uso típicos para la replicación lógica son:

• Enviar cambios incrementales en una sola base de datos (o un subconjunto de una base de datos) a los suscriptores a medida que ocurren.
• Compartir un subconjunto de la base de datos entre varias bases de datos.
• Activar la activación de cambios individuales a medida que llegan al suscriptor.
• Consolidación de múltiples bases de datos en una sola.
• Proporcionar acceso a datos replicados a diferentes grupos de usuarios.

La base de datos de suscriptores se comporta de la misma manera que cualquier otra instancia de PostgreSQL y se puede utilizar como publicador para otras bases de datos definiendo sus publicaciones.

Cuando la aplicación trata al suscriptor como de solo lectura, no habrá conflictos de una sola suscripción. Por otro lado, si hay otras escrituras realizadas por una aplicación o por otros suscriptores del mismo conjunto de tablas, pueden surgir conflictos.

PostgreSQL admite ambos mecanismos al mismo tiempo. La replicación lógica permite un control detallado sobre la replicación y la seguridad de los datos.

Modos de replicación

Existen principalmente dos modos de replicación de PostgreSQL: síncrona y asíncrona. La replicación síncrona permite que los datos se escriban en el servidor primario y secundario al mismo tiempo, mientras que la replicación asíncrona garantiza que los datos se escriban primero en el host y luego se copien en el servidor secundario.

En la replicación en modo síncrono, las transacciones en la base de datos principal se consideran completas solo cuando esos cambios se han replicado en todas las réplicas. Todos los servidores de réplica deben estar disponibles todo el tiempo para que las transacciones se completen en el principal. El modo síncrono de replicación se utiliza en entornos transaccionales de alto nivel con requisitos de conmutación por error inmediatos.

En el modo asíncrono, las transacciones en el servidor principal se pueden declarar completas cuando los cambios se han realizado solo en el servidor principal. Estos cambios luego se replican en las réplicas más adelante en el tiempo. Los servidores de réplica pueden permanecer desincronizados durante un período determinado, lo que se denomina retraso de replicación. En el caso de un bloqueo, puede ocurrir una pérdida de datos, pero la sobrecarga proporcionada por la replicación asíncrona es pequeña, por lo que es aceptable en la mayoría de los casos (no sobrecarga al host). La conmutación por error de la base de datos principal a la base de datos secundaria lleva más tiempo que la replicación síncrona.

Cómo configurar la replicación de PostgreSQL

En esta sección, demostraremos cómo configurar el proceso de replicación de PostgreSQL en un sistema operativo Linux. Para esta instancia, usaremos Ubuntu 18.04 LTS y PostgreSQL 10.

¡Vamos a profundizar en!

Instalación

Comenzará instalando PostgreSQL en Linux con estos pasos:

1. En primer lugar, tendría que importar la clave de firma de PostgreSQL escribiendo el siguiente comando en la terminal:

    wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O- | sudo apt-key add -

2. Luego, agregue el repositorio de PostgreSQL escribiendo el siguiente comando en la terminal:

    echo "deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main" | sudo tee /etc/apt/sources.list.d/postgresql.list

3. Actualice el índice del repositorio escribiendo el siguiente comando en la terminal:

    sudo apt-get update

4. Instale el paquete PostgreSQL usando el comando apt:

    sudo apt-get install -y postgresql-10

5. Finalmente, configure la contraseña para el usuario de PostgreSQL usando el siguiente comando:

    sudo passwd postgres

La instalación de PostgreSQL es obligatoria tanto para el servidor principal como para el secundario antes de iniciar el proceso de replicación de PostgreSQL.

Una vez que haya configurado PostgreSQL para ambos servidores, puede pasar a la configuración de replicación del servidor primario y secundario.

Configuración de la replicación en el servidor principal

Realice estos pasos una vez que haya instalado PostgreSQL en los servidores principal y secundario.

1. En primer lugar, inicie sesión en la base de datos PostgreSQL con el siguiente comando:

    su - postgres

2. Cree un usuario de replicación con el siguiente comando:

    psql -c "CREATEUSER replication REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD'YOUR_PASSWORD';"

3. Edite pg_hba.cnf con cualquier aplicación nano en Ubuntu y agregue la siguiente configuración: comando de edición de archivos

    nano /etc/postgresql/10/main/pg_hba.conf

   Para configurar el archivo, use el siguiente comando:

    host replication replication MasterIP/24 md5

4. Abra y edite postgresql.conf y coloque la siguiente configuración en el servidor principal:

    nano /etc/postgresql/10/main/postgresql.conf

   Utilice los siguientes ajustes de configuración:
   

    listen_addresses = 'localhost,MasterIP'

    wal_level = replica

    wal_keep_segments = 64

    max_wal_senders = 10

5. Finalmente, reinicie PostgreSQL en el servidor principal principal:

 systemctl restart postgresql

Ahora ha completado la configuración en el servidor principal.

Configuración de la replicación en el servidor secundario

Siga estos pasos para configurar la replicación en el servidor secundario:

1. Inicie sesión en PostgreSQL RDMS con el siguiente comando:

    su - postgres

2. Detenga el servicio de PostgreSQL para que podamos trabajar en él con el siguiente comando:

    systemctl stop postgresql

3. Edite el archivo pg_hba.conf con este comando y agregue la siguiente configuración:
   Editar comando
   

    nano /etc/postgresql/10/main/pg_hba.conf

   Configuración
   

    host replication replication MasterIP/24 md5

4. Abra y edite postgresql.conf en el servidor secundario y coloque la siguiente configuración o descomente si está comentada: Editar comando
   
   Configuración
   

    nano /etc/postgresql/10/main/postgresql.conf

    listen_addresses = 'localhost,SecondaryIP'

    wal_keep_segments = 64

    wal_level = replica

    hot_standby = on

    max_wal_senders = 10

   SecundariaIP es la dirección del servidor secundario

5. Acceda al directorio de datos de PostgreSQL en el servidor secundario y elimine todo:

    cd /var/lib/postgresql/10/main

    rm -rfv *

6. Copie los archivos del directorio de datos del servidor primario de PostgreSQL en el directorio de datos del servidor secundario de PostgreSQL y escriba este comando en el servidor secundario:

    pg_basebackup -h MasterIP -D /var/lib/postgresql/11/main/ -P -U

    replication --wal-method=fetch

7. Ingrese la contraseña de PostgreSQL del servidor principal y presione enter. A continuación, agregue el siguiente comando para la configuración de recuperación: Editar comando
   

    nano /var/lib/postgresql/10/main/recovery.conf

   Configuración
   

    standby_mode = 'on' primary_conninfo = 'host=MasterIP port=5432 user=replication password=YOUR_PASSWORD' trigger_file = '/tmp/MasterNow'

   Aquí, YOUR_PASSWORD es la contraseña para el usuario de replicación en el servidor principal creado por PostgreSQL.

8. Una vez que se haya establecido la contraseña, deberá reiniciar la base de datos PostgreSQL secundaria ya que se detuvo:

 systemctl start postgresql

Probar su configuración

Ahora que hemos llevado a cabo los pasos, probemos el proceso de replicación y observemos la base de datos del servidor secundario. Para ello creamos una tabla en el servidor primario y observamos si lo mismo se refleja en el servidor secundario.

Hagámoslo.

1. Dado que estamos creando la tabla en el servidor principal, debe iniciar sesión en el servidor principal:

    su - postgres psql

2. Ahora creamos una tabla simple llamada 'testtable' e insertamos datos en la tabla ejecutando las siguientes consultas de PostgreSQL en la terminal:

    CREATE TABLE testtable (websites varchar(100)); INSERT INTO testtable VALUES ('section.com'); INSERT INTO testtable VALUES ('google.com'); INSERT INTO testtable VALUES ('github.com');

3. Observe la base de datos PostgreSQL del servidor secundario iniciando sesión en el servidor secundario:

    su - postgres psql

4. Ahora, verificamos si la tabla 'testtable' existe y podemos devolver los datos ejecutando las siguientes consultas de PostgreSQL en la terminal. Este comando esencialmente muestra la tabla completa.

    select * from testtable;

Esta es la salida de la tabla de prueba:

 | websites | ------------------- | section.com | | google.com | | github.com | --------------------

Debería poder observar los mismos datos que en el servidor principal.

Si ve lo anterior, ¡entonces ha llevado a cabo con éxito el proceso de replicación!

¿Cuáles son los pasos de conmutación por error manual de PostgreSQL?

Repasemos los pasos para una conmutación por error manual de PostgreSQL:

1. Bloquee el servidor principal.
2. Promocione el servidor en espera ejecutando el siguiente comando en el servidor en espera:

    ./pg_ctl promote -D ../sb_data/ server promoting

3. Conéctese al servidor en espera promocionado e inserte una fila:

    -bash-4.2$ ./edb-psql -p 5432 edb Password: psql.bin (10.7) Type "help" for help. edb=# insert into abc values (4,'Four');

Si la inserción funciona bien, entonces el servidor en espera, anteriormente un servidor de solo lectura, se ha promovido como el nuevo servidor principal.

Cómo automatizar la conmutación por error en PostgreSQL

Configurar la conmutación por error automática es fácil.

Necesitará el administrador de conmutación por error EDB PostgreSQL (EFM). Después de descargar e instalar EFM en cada nodo principal y en espera, puede crear un clúster de EFM, que consta de un nodo principal, uno o más nodos en espera y un nodo testigo opcional que confirma las afirmaciones en caso de falla.

EFM supervisa continuamente el estado del sistema y envía alertas por correo electrónico en función de los eventos del sistema. Cuando ocurre una falla, cambia automáticamente al servidor en espera más actualizado y reconfigura todos los demás servidores en espera para reconocer el nuevo nodo principal.

También reconfigura los balanceadores de carga (como pgPool) y evita que ocurra el "cerebro dividido" (cuando dos nodos piensan que son primarios).

Resumen

Debido a las grandes cantidades de datos, la escalabilidad y la seguridad se han convertido en dos de los criterios más importantes en la gestión de bases de datos, especialmente en un entorno transaccional. Si bien podemos mejorar la escalabilidad verticalmente agregando más recursos/hardware a los nodos existentes, no siempre es posible, a menudo debido al costo o las limitaciones de agregar nuevo hardware.

Por lo tanto, se requiere escalabilidad horizontal, lo que significa agregar más nodos a los nodos de red existentes en lugar de mejorar la funcionalidad de los nodos existentes. Aquí es donde la replicación de PostgreSQL entra en escena.
Para proteger la integridad de su sitio, es vital crear medidas de seguridad contra la posibilidad de tiempo de inactividad o pérdida de datos. Obtenga más información en esta guía Haga clic para twittear
En este artículo, analizamos los tipos de replicaciones de PostgreSQL, los beneficios, los modos de replicación, la instalación y la conmutación por error de PostgreSQL entre SMR y MMR. Ahora vamos a escuchar de usted.

¿Cuál sueles implementar? ¿Qué característica de la base de datos es la más importante para usted y por qué? ¡Nos encantaría leer tus pensamientos! Compártalos en la sección de comentarios a continuación.