Configurar la replicaci\u00f3n entre dos bases de datos ofrece tolerancia a los fallos frente a percances inesperados. Se considera la mejor estrategia para conseguir una alta disponibilidad durante los desastres.<\/p>\n
En este art\u00edculo, nos adentraremos en las diferentes estrategias que pueden implementar los desarrolladores de backend<\/a> para conseguir una replicaci\u00f3n de PostgreSQL sin problemas. La replicaci\u00f3n PostgreSQL se define como el proceso de copiar datos de un servidor de base de datos PostgreSQL<\/a> a otro servidor. El servidor de la base de datos de origen tambi\u00e9n se conoce como servidor \u00abprimario\u00bb, mientras que el servidor de la base de datos que recibe los datos copiados se conoce como servidor \u00abr\u00e9plica\u00bb.<\/p>\n La base de datos PostgreSQL sigue un modelo de replicaci\u00f3n sencillo, en el que todas las escrituras van a un nodo primario. El nodo primario puede entonces aplicar estos cambios y difundirlos a los nodos secundarios.<\/p>\n La conmutaci\u00f3n por error es un m\u00e9todo para recuperar los datos si el servidor primario falla<\/a> por cualquier motivo. Siempre que hayas configurado PostreSQL para gestionar la replicaci\u00f3n de tu flujo f\u00edsico, t\u00fa \u2014 y tus usuarios \u2014 estar\u00e9is protegidos contra el tiempo de inactividad debido a un fallo del servidor primario.<\/p>\n Ten en cuenta que el proceso de conmutaci\u00f3n por error puede tardar un poco en configurarse e iniciarse. No hay herramientas incorporadas para monitorear y evaluar los fallos del servidor en PostgreSQL, as\u00ed que tendr\u00e1s que ser creativo.<\/p>\n Afortunadamente, ya no tienes que depender de PostgreSQL para la conmutaci\u00f3n por error. Hay herramientas dedicadas que permiten la conmutaci\u00f3n por error autom\u00e1tica y el cambio autom\u00e1tico al standby, reduciendo el tiempo de inactividad de la base de datos<\/a>.<\/p>\n Al configurar la replicaci\u00f3n por error, pr\u00e1cticamente garantizas una alta disponibilidad al asegurar que los servidores en espera est\u00e9n disponibles si el servidor primario se colapsa alguna vez.<\/p>\n He aqu\u00ed algunas de las principales ventajas de aprovechar la replicaci\u00f3n PostgreSQL:<\/p>\n Generalmente, la gente cree que cuando se est\u00e1 jugando con una arquitectura primaria y secundaria, s\u00f3lo hay una manera de configurar las copias de seguridad<\/a> y la replicaci\u00f3n. Sin embargo, las implementaciones de PostgreSQL pueden seguir cualquiera de estos tres m\u00e9todos<\/a>:<\/p>\n La replicaci\u00f3n en streaming de PostgreSQL, tambi\u00e9n conocida como replicaci\u00f3n WAL, puede configurarse sin problemas despu\u00e9s de instalar PostgreSQL en todos los servidores. Este enfoque de la replicaci\u00f3n se basa en el traslado de los archivos WAL del primario a la base de datos de destino.<\/p>\n Puedes implementar la replicaci\u00f3n en flujo de PostgreSQL utilizando una configuraci\u00f3n primaria-secundaria. El servidor primario es la instancia principal que maneja la base de datos primaria y todas sus operaciones. El servidor secundario act\u00faa como instancia complementaria y ejecuta en s\u00ed mismo todos los cambios realizados en la base de datos primaria, generando una copia id\u00e9ntica en el proceso. El primario es el servidor de lectura\/escritura, mientras que el secundario es de mera lectura.<\/p>\n Para este m\u00e9todo, tienes que configurar tanto el nodo primario como el nodo secundario. Las siguientes secciones dilucidar\u00e1n los pasos necesarios para configurarlos con facilidad.<\/p>\n Puedes configurar el nodo primario para la replicaci\u00f3n en streaming llevando a cabo los siguientes pasos:<\/p>\n Para inicializar la base de datos<\/a>, puedes aprovechar el comando de utilidad El usuario tendr\u00e1 que proporcionar una contrase\u00f1a y un nombre de usuario para la consulta dada. La palabra clave de replicaci\u00f3n se utiliza para dar al usuario los privilegios necesarios. Un ejemplo de consulta ser\u00eda algo as\u00ed<\/p>\n A continuaci\u00f3n, puedes configurar las propiedades de streaming con el archivo de configuraci\u00f3n de PostgreSQL (postgresql.conf<\/strong>) que se puede modificar como sigue:<\/p>\n Aqu\u00ed tienes un poco de informaci\u00f3n sobre los par\u00e1metros utilizados en el fragmento anterior:<\/p>\n Despu\u00e9s de haber modificado los par\u00e1metros en el archivo postgresql.conf<\/strong>, una nueva entrada de replicaci\u00f3n en el archivo pg_hba.conf<\/strong> puede permitir que los servidores establezcan una conexi\u00f3n entre s\u00ed para la replicaci\u00f3n.<\/p>\n Normalmente puedes encontrar este archivo en el directorio de datos de PostgreSQL. Puedes utilizar el siguiente fragmento de c\u00f3digo para ello:<\/p>\n Una vez ejecutado el fragmento de c\u00f3digo, el servidor primario permite que un usuario llamado Para configurar el nodo en espera para la replicaci\u00f3n en streaming, sigue estos pasos:<\/p>\n Para configurar el nodo en espera, aprovecha la utilidad Los par\u00e1metros utilizados en la sintaxis mencionada son los siguientes:<\/p>\n A continuaci\u00f3n, tienes que comprobar si existe el archivo de configuraci\u00f3n de la replicaci\u00f3n. Si no existe, puedes generar el archivo de configuraci\u00f3n de la replicaci\u00f3n como recovery.conf<\/strong>.<\/p>\n Debes crear este archivo en el directorio de datos de la instalaci\u00f3n de PostgreSQL. Puedes generarlo autom\u00e1ticamente utilizando la opci\u00f3n El archivo recovery. conf<\/strong> debe contener los siguientes comandos:<\/p>\n Los par\u00e1metros utilizados en los comandos mencionados son los siguientes<\/p>\n Para establecer una conexi\u00f3n, debes proporcionar el nombre de usuario, la direcci\u00f3n IP y la contrase\u00f1a como valores del par\u00e1metro primary_conninfo. Por ejemplo:<\/p>\n Por \u00faltimo, puedes reiniciar el servidor secundario para completar el proceso de configuraci\u00f3n.<\/p>\n Sin embargo, la replicaci\u00f3n en streaming conlleva varios retos, como por ejemplo:<\/p>\n El enfoque del dispositivo de bloque replicado depende de la duplicaci\u00f3n de discos (tambi\u00e9n conocida como replicaci\u00f3n de vol\u00famenes). En este enfoque, los cambios se escriben en un volumen persistente que se replica sincr\u00f3nicamente en otro volumen.<\/p>\n La ventaja a\u00f1adida de este enfoque es su compatibilidad y la durabilidad de los datos en entornos de nube con todas las bases de datos relacionales, como PostgreSQL, MySQL y SQL Server<\/a>, por nombrar algunas.<\/p>\n Sin embargo, el m\u00e9todo de r\u00e9plica en disco de PostgreSQL necesita que se repliquen tanto los datos del registro WAL como los de la tabla. Dado que cada escritura en la base de datos tiene que pasar por la red de forma sincr\u00f3nica, no puedes permitirte perder un solo byte, ya que eso podr\u00eda dejar tu base de datos en un estado corrupto.<\/p>\n Este m\u00e9todo se aprovecha normalmente con Azure PostgreSQL y Amazon RDS.<\/p>\n La WAL se compone de archivos de segmentos (16 MB por defecto). Cada segmento tiene uno o m\u00e1s registros. Un registro de secuencia de registro (LSN) es un indicador de un registro en la WAL, que permite conocer la posici\u00f3n\/ubicaci\u00f3n en la que se ha guardado el registro en el archivo de registro.<\/p>\n Un servidor en espera aprovecha los segmentos de WAL \u2013 tambi\u00e9n conocidos como XLOGS en la terminolog\u00eda de PostgreSQL\u2013 para replicar continuamente los cambios de su servidor primario. Puedes utilizar el registro de escritura anticipada para garantizar la durabilidad y la atomicidad en un SGBD, serializando trozos de datos byte-array (cada uno con un LSN \u00fanico) en un almacenamiento estable antes de que se apliquen a una base de datos.<\/p>\n La aplicaci\u00f3n de una mutaci\u00f3n a una base de datos puede llevar a varias operaciones del sistema de archivos. Una cuesti\u00f3n pertinente que se plantea es c\u00f3mo puede una base de datos asegurar la atomicidad en caso de fallo del servidor debido a un corte de energ\u00eda mientras estaba en medio de una actualizaci\u00f3n del sistema de archivos. Cuando una base de datos arranca, inicia un proceso de arranque o r\u00e9plica que puede leer los segmentos de WAL disponibles y los compara con el LSN almacenado en cada p\u00e1gina de datos (cada p\u00e1gina de datos est\u00e1 marcada con el LSN del \u00faltimo registro de WAL que afecta a la p\u00e1gina).<\/p>\n La replicaci\u00f3n en flujo perfecciona el proceso de env\u00edo de registros. En lugar de esperar al cambio de WAL, los registros se env\u00edan a medida que se crean, lo que disminuye el retraso de la replicaci\u00f3n.<\/p>\n La replicaci\u00f3n en flujo tambi\u00e9n supera el env\u00edo de registros porque el servidor en espera se enlaza con el servidor primario a trav\u00e9s de la red aprovechando un protocolo de replicaci\u00f3n. El servidor primario puede entonces enviar los registros WAL directamente a trav\u00e9s de esta conexi\u00f3n sin tener que depender de los scripts proporcionados por el usuario final.<\/p>\n El env\u00edo de registros se define como la copia de los archivos de registro a otro servidor PostgreSQL para generar otro servidor en espera mediante la replicaci\u00f3n de los archivos WAL. Este servidor est\u00e1 configurado para trabajar en modo de recuperaci\u00f3n, y su \u00fanico prop\u00f3sito es aplicar los nuevos archivos WAL a medida que aparecen.<\/p>\n Este servidor secundario se convierte entonces en una copia de seguridad caliente del servidor PostgreSQL primario. Tambi\u00e9n puede configurarse para ser una r\u00e9plica de lectura, en la que puede ofrecer consultas de s\u00f3lo lectura, lo que tambi\u00e9n se denomina hot standby.<\/p>\n Duplicar los archivos WAL a medida que se crean en cualquier ubicaci\u00f3n distinta del subdirectorio El script puede aprovechar el comando Otras configuraciones basadas en el registro son:<\/p>\n Un proceso conocido como receptor de WAL, que se ejecuta en el servidor en espera, aprovecha los detalles de conexi\u00f3n proporcionados en el par\u00e1metro Para iniciar la replicaci\u00f3n en streaming, el frontend puede enviar el par\u00e1metro de replicaci\u00f3n dentro del mensaje de inicio. Un valor booleano de verdadero, s\u00ed, 1 u ON permite al backend<\/a> saber que debe entrar en modo de replicaci\u00f3n f\u00edsica walsender.<\/p>\n El emisor de la WAL es otro proceso que se ejecuta en el servidor primario y se encarga de enviar los registros de la WAL al servidor en espera a medida que se generan. El receptor de la WAL guarda los registros de la WAL en la WAL como si fueran creados por la actividad de los clientes conectados localmente.<\/p>\n Una vez que los registros de la WAL llegan a los archivos de segmentos de la WAL, el servidor en espera sigue reproduciendo constantemente la WAL para que el primario y el en espera est\u00e9n actualizados.<\/p>\n En esta secci\u00f3n, conocer\u00e1s mejor los modelos m\u00e1s utilizados (replicaci\u00f3n monom\u00e1ster y multim\u00e1ster), los tipos (replicaci\u00f3n f\u00edsica y l\u00f3gica) y los modos (s\u00edncrono y as\u00edncrono) de la replicaci\u00f3n PostgreSQL.<\/p>\n La escalabilidad significa a\u00f1adir m\u00e1s recursos\/hardware a los nodos existentes para mejorar la capacidad de la base de datos de almacenar y procesar m\u00e1s datos, lo que puede conseguirse de forma horizontal y vertical. La replicaci\u00f3n de PostgreSQL es un ejemplo de escalabilidad horizontal que es mucho m\u00e1s dif\u00edcil de implementar que la escalabilidad vertical. Podemos conseguir la escalabilidad horizontal principalmente mediante la replicaci\u00f3n monom\u00e1ster (SMR) y la replicaci\u00f3n multim\u00e1ster (MMR).<\/p>\n La replicaci\u00f3n monom\u00e1ster permite que los datos se modifiquen s\u00f3lo en un nodo, y estas modificaciones se replican en uno o m\u00e1s nodos. Las tablas replicadas en la base de datos de r\u00e9plica no pueden aceptar ning\u00fan cambio, excepto los del servidor primario. Incluso si lo hacen, los cambios no se replican al servidor primario.<\/p>\n La mayor\u00eda de las veces, la SMR es suficiente para la aplicaci\u00f3n porque es menos complicada de configurar y gestionar, adem\u00e1s de que no hay posibilidades de conflictos. La replicaci\u00f3n monom\u00e1ster tambi\u00e9n es unidireccional, ya que los datos de replicaci\u00f3n fluyen en una direcci\u00f3n principalmente, desde la base de datos primaria a la r\u00e9plica.<\/p>\n En algunos casos, la SMR por s\u00ed sola puede no ser suficiente, y puedes necesitar implementar la MMR. La MMR permite que m\u00e1s de un nodo act\u00fae como nodo primario. Los cambios en las filas de las tablas en m\u00e1s de una base de datos primaria designada se replican en sus tablas hom\u00f3logas en todas las dem\u00e1s bases de datos primarias. En este modelo, se suelen emplear esquemas de resoluci\u00f3n de conflictos para evitar problemas como las claves primarias duplicadas.<\/p>\n El uso de MMR tiene algunas ventajas, por ejemplo:<\/p>\n Sin embargo, el inconveniente de aplicar el MMR es la complejidad y su dificultad para resolver los conflictos.<\/p>\n Varias ramas y aplicaciones ofrecen soluciones de MMR, ya que PostgreSQL no lo soporta de forma nativa. Estas soluciones pueden ser de c\u00f3digo abierto<\/a>, gratuitas o de pago. Una de estas extensiones<\/a> es la replicaci\u00f3n bidireccional (BDR), que es as\u00edncrona y se basa en la funci\u00f3n de decodificaci\u00f3n l\u00f3gica de PostgreSQL.<\/p>\n Como la aplicaci\u00f3n BDR replica las transacciones en otros nodos, la operaci\u00f3n de r\u00e9plica puede fallar si hay un conflicto entre la transacci\u00f3n que se aplica y la transacci\u00f3n consignada en el nodo receptor.<\/p>\n Hay dos tipos de replicaci\u00f3n PostgreSQL: la l\u00f3gica y la f\u00edsica.<\/p>\n Una simple operaci\u00f3n l\u00f3gica<\/em> La replicaci\u00f3n f\u00edsica suele tratar con archivos y directorios. No sabe qu\u00e9 representan estos archivos y directorios. Estos m\u00e9todos se utilizan para mantener una copia completa de todos los datos de un \u00fanico cl\u00faster, normalmente en otra m\u00e1quina, y se realizan a nivel de sistema de archivos o de disco y utilizan direcciones de bloque exactas.<\/p>\n La replicaci\u00f3n l\u00f3gica es una forma de reproducir las entidades de datos y sus modificaciones, bas\u00e1ndose en su identidad de replicaci\u00f3n (normalmente una clave primaria). A diferencia de la replicaci\u00f3n f\u00edsica, se ocupa de las bases de datos, las tablas y las operaciones DML y se realiza a nivel de cl\u00faster de base de datos. Utiliza un modelo de publicaci\u00f3n<\/em> y suscripci\u00f3n<\/em> en el que uno o varios suscriptores<\/em> est\u00e1n suscritos a una o varias publicaciones<\/em> en un nodo editor<\/em>.<\/p>\n El proceso de replicaci\u00f3n comienza tomando una instant\u00e1nea de los datos en la base de datos del editor y luego la copia al suscriptor. Los suscriptores extraen los datos de las publicaciones a las que se suscriben y pueden volver a publicar los datos m\u00e1s tarde para permitir la replicaci\u00f3n en cascada o configuraciones m\u00e1s complejas. El suscriptor aplica los datos en el mismo orden que el editor, de modo que se garantiza la coherencia transaccional de las publicaciones dentro de una misma suscripci\u00f3n, tambi\u00e9n conocida como replicaci\u00f3n transaccional.<\/p>\n Los casos de uso t\u00edpicos de la replicaci\u00f3n l\u00f3gica son:<\/p>\n La base de datos del suscriptor se comporta de la misma manera que cualquier otra instancia de PostgreSQL y puede utilizarse como editor para otras bases de datos definiendo sus publicaciones.<\/p>\n Si el suscriptor es tratado como de s\u00f3lo lectura por la aplicaci\u00f3n, no habr\u00e1 conflictos desde una \u00fanica suscripci\u00f3n. En cambio, si hay otras escrituras realizadas por una aplicaci\u00f3n o por otros suscriptores en el mismo conjunto de tablas, pueden surgir conflictos.<\/p>\n PostgreSQL admite ambos mecanismos de forma concurrente. La replicaci\u00f3n l\u00f3gica permite un control detallado tanto de la replicaci\u00f3n de datos como de la seguridad.<\/p>\n Existen principalmente dos modos de replicaci\u00f3n en PostgreSQL: sincr\u00f3nica y asincr\u00f3nica. La replicaci\u00f3n sincr\u00f3nica permite que los datos se escriban en el servidor primario y en el secundario al mismo tiempo, mientras que la replicaci\u00f3n asincr\u00f3nica garantiza que los datos se escriban primero en el host y luego se copien en el servidor secundario.<\/p>\n En la replicaci\u00f3n en modo s\u00edncrono, las transacciones en la base de datos primaria se consideran completas s\u00f3lo cuando esos cambios se han replicado a todas las r\u00e9plicas. Los servidores de r\u00e9plica deben estar disponibles todo el tiempo para que las transacciones se completen en el primario. El modo s\u00edncrono de replicaci\u00f3n se utiliza en entornos transaccionales de alto nivel con requisitos de conmutaci\u00f3n por error inmediatos.<\/p>\n En el modo as\u00edncrono, las transacciones en el servidor primario pueden declararse completas cuando los cambios se han realizado s\u00f3lo en el servidor primario. Estos cambios se replican posteriormente en las r\u00e9plicas. Los servidores de r\u00e9plica pueden permanecer desincronizados durante un tiempo determinado, llamado retraso de replicaci\u00f3n. En caso de ca\u00edda, puede producirse una p\u00e9rdida de datos, pero la sobrecarga que proporciona la replicaci\u00f3n as\u00edncrona es peque\u00f1a, por lo que es aceptable en la mayor\u00eda de los casos (no sobrecarga al servidor). La conmutaci\u00f3n por error de la base de datos primaria a la secundaria tarda m\u00e1s que la replicaci\u00f3n sincr\u00f3nica.<\/p>\n En esta secci\u00f3n mostraremos c\u00f3mo configurar el proceso de replicaci\u00f3n de PostgreSQL en un sistema operativo Linux. En este caso, utilizaremos Ubuntu 18.04 LTS y PostgreSQL 10.<\/p>\n
\n\u00bfQu\u00e9 es la Replicaci\u00f3n PostgreSQL?<\/h2>\n
![\"Una](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
\u00bfQu\u00e9 es la Conmutaci\u00f3n por Error Autom\u00e1tica?<\/h3>\n
Ventajas de Utilizar la Replicaci\u00f3n PostgreSQL<\/h2>\n
\n
C\u00f3mo Funciona la Replicaci\u00f3n PostgreSQL<\/h2>\n
\n
M\u00e9todo 1: Streaming<\/h3>\n
Configurar el Nodo Primario<\/h4>\n
Paso 1: Inicializar la Base de Datos<\/h5>\n
initdb<\/code>. A continuaci\u00f3n, puedes crear un nuevo usuario con privilegios de replicaci\u00f3n utilizando el siguiente comando:<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\nPaso 2: Configurar las Propiedades de Streaming<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code><\/strong>: Este par\u00e1metro es necesario para la funci\u00f3n pg_rewind<\/code>, que resulta muy \u00fatil cuando el servidor secundario est\u00e1 desincronizado con el primario.<\/li>\nwal_level<\/code><\/strong>: Puedes utilizar este par\u00e1metro para habilitar la replicaci\u00f3n en flujo de PostgreSQL, con valores posibles como minimal<\/code>, replica<\/code>, o logical<\/code>.<\/li>\nmax_wal_size<\/code><\/strong>: Se puede utilizar para especificar el tama\u00f1o de los archivos WAL que se pueden conservar en los archivos de registro.<\/li>\nhot_standby<\/code><\/strong>: Puedes aprovechar este par\u00e1metro para establecer una conexi\u00f3n de lectura con el secundario cuando est\u00e1 configurado como ON.<\/li>\nmax_wal_senders<\/code><\/strong>: Puedes utilizar max_wal_senders<\/code> para especificar el n\u00famero m\u00e1ximo de conexiones concurrentes que pueden establecerse con los servidores en espera.<\/li>\n<\/ul>\nPaso 3: Crear una Nueva Entrada<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code> se conecte y act\u00fae como servidor en espera utilizando la IP especificada para la replicaci\u00f3n. Por ejemplo:<\/p>\n host replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nConfigurar el Nodo En Espera<\/h4>\n
Paso 1: Copia de Seguridad del Nodo Primario<\/h5>\n
pg_basebackup<\/code> para generar una copia de seguridad del nodo primario. Esto servir\u00e1 como punto de partida para el nodo en espera. Puedes utilizar esta utilidad con la siguiente sintaxis:<\/p>\n pg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code><\/strong>: Puedes utilizarlo para mencionar el host primario.<\/li>\n-D<\/code><\/strong>: Este par\u00e1metro indica el directorio en el que est\u00e1s trabajando actualmente.<\/li>\n-C<\/code><\/strong>: Puedes utilizarlo para establecer los puntos de control.<\/li>\n-X<\/code><\/strong>: Este par\u00e1metro puede utilizarse para incluir los archivos de registro transaccional necesarios.<\/li>\n-W<\/code><\/strong>: Puedes utilizar este par\u00e1metro para solicitar al usuario una contrase\u00f1a antes de enlazar con la base de datos.<\/li>\n<\/ul>\nPaso 2: Configurar el Archivo de Configuraci\u00f3n de la Replicaci\u00f3n<\/h5>\n
-R<\/code> dentro de la utilidad pg_basebackup<\/code>.<\/p>\nstandby_mode = 'on'\n\nprimary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=\"host_name\"'\n\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n\n
primary_conninfo<\/code><\/strong>: Puedes utilizarlo para establecer una conexi\u00f3n entre los servidores primario y secundario aprovechando una cadena de conexi\u00f3n.<\/li>\nstandby_mode<\/code><\/strong>: Este par\u00e1metro puede hacer que el servidor primario se inicie como el secundario cuando se ponga en marcha.<\/li>\nrecovery_target_timeline<\/code><\/strong>: Puedes utilizarlo para establecer el tiempo de recuperaci\u00f3n.<\/li>\n<\/ul>\n primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\nPaso 3: Reiniciar el Servidor Secundario<\/h5>\n
\n
M\u00e9todo 2: Dispositivo de Bloque Replicado<\/h3>\n
M\u00e9todo 3: WAL<\/h3>\n
Replicaci\u00f3n Basada en el Env\u00edo de Registros (Nivel de Bloque)<\/h4>\n
Replicaci\u00f3n Basada en el Env\u00edo de Registros (Nivel de Archivo)<\/h4>\n
Archivo WAL Continuo<\/h4>\n
pg_wal<\/code> para archivarlos se conoce como archivo WAL. PostgreSQL llamar\u00e1 a un script dado por el usuario para archivar, cada vez que se cree un archivo WAL.<\/p>\nscp<\/code> para duplicar el archivo en una o varias ubicaciones, como un soporte NFS. Una vez archivados, los archivos de segmento WAL pueden aprovecharse para recuperar la base de datos en cualquier momento.<\/p>\n\n
Detalles del Protocolo de Streaming WAL<\/h4>\n
primary_conninfo<\/code> de recovery.conf<\/strong> y se conecta al servidor primario aprovechando una conexi\u00f3n TCP\/IP.<\/p>\n![\"Un](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
Elementos de la Replicaci\u00f3n PostgreSQL<\/h2>\n
Modelos de Replicaci\u00f3n de Bases de Datos PostgreSQL<\/h3>\n
\n
Tipos de Replicaci\u00f3n PostgreSQL<\/h3>\n
initdb<\/code>\u00a0realizar\u00eda la operaci\u00f3n f\u00edsica de crear un directorio base para un cl\u00faster. Asimismo, una simple operaci\u00f3n l\u00f3gica<\/em> \u00abCREATE DATABASE<\/code>\u00bb realizar\u00eda la operaci\u00f3n f\u00edsica<\/em> de crear un subdirectorio en el directorio base.<\/p>\n\n
Modos de Replicaci\u00f3n<\/h3>\n
C\u00f3mo Configurar la Replicaci\u00f3n PostgreSQL<\/h2>\n