Replicación en MySQL

Aquí hay una breve descripción de cómo inicializar una replicación completa de su servidor MySQL. Asume que quiere replicar todas las bases de datos en el maestro y no tiene una replicación préviamente configurarla. Necesita parar el servidor maestro brevemente para completar los pasos descritos aquí.Este procedimiento está escrito en términos de inicializar un esclavo único, pero puede usarlo para inicializar múltiples esclavos.Mientras este método es el más directo para inicializar un esclavo, no es el único. Por ejemplo, si tiene una muestra de los datos del maestro, y el maestro tiene su ID de servidor y el log binario activo, puede preparar un esclavo sin parar el maestro o incluso sin bloquear actualizaciones para ello. Para más detalles, consulte Sección 6.9, “Preguntas y respuestas sobre replicación”.Si quiere administrar la inicialización de una replicación MySQL, sugerimos que lea este capítulo entero y pruebe todos los comandos mencionados enSección 13.6.1, “Sentencias SQL para el control de servidores maestros” ySección 13.6.2, “Sentencias SQL para el control de servidores esclavos”. También debe familiarizarse con las opciones de arranque de replicación descritas en Sección 6.8, “Opciones de arranque de replicación”.Nota: este procedimiento y algunos de los comandos de replicación SQL mostrados en secciones posteriores necesitan el privilegio SUPER.1. Asegúrese de que las versiones de MySQL instalado en el maestro y en el esclavo son

compatibles según dice la tabla mostrada en Sección 6.5, “Compatibilidad entre versiones de MySQL con respecto a la replicación”. Idealmente, debe usar la versión más reciente de MySQL en maestro y servidor.Por favor no reporte bugs hasta que ha verificado que el problema está presente en la última versión de MySQL.

2. Prepare una cuenta en el maestro que pueda usar el esclavo para conectar. Este cuenta debe tener el privilegioREPLICATION SLAVE . Si la cuenta se usa sólo para replicación (lo que se recomienda), no necesita dar ningún privilegio adicional. (Para información sobre preparar cuentas de usuarios y privilegios, consulte Sección 5.7, “Gestión de la cuenta de usuario MySQL”.)Suponga que su dominio es mydomain.com y que quiere crear una cuenta con un nombre de usuario de replique puedan usar los esclavos para acceder al maestro desde cualquier equipo en su dominio usando una contraseña de slavepass. Para crear la cuenta, use el comando GRANT:mysql> GRANT REPLICATION SLAVE ON *.* -> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';Si quiere usar los comandos LOAD TABLE FROM MASTER o LOAD DATA FROM MASTER desde el servidor esclavo, necesita dar a esta cuenta privilegios adicionales: De a la cuenta el privilegio global SUPER y RELOAD . De el privilegio SELECT para todas las tablas que quiere cargar. Cualquier tabla

maestra desde la que la cuenta no puede hacer un SELECT se ignoran por LOAD DATA FROM MASTER.

3. Si usa sólo tablas MyISAM , vuelque todas las tablas y bloquee los comandos de escritura ejecutando un comando FLUSH TABLES WITH READ LOCK :mysql> FLUSH TABLES WITH READ LOCK;Deje el cliente en ejecución desde el que lanza el comando FLUSH TABLES para que pueda leer los efectos del bloqueo. (Si sale del cliente, el bloqueo se libera.) Luego tome una muestra de los datos de su servidor maestro.La forma más fácil de crear una muestra es usar un programa de archivo para crear una copia de seguidad binaria de las bases de datos en su directorio de datos del maestro. Por ejemplo. use tar en Unix, oPowerArchiver, WinRAR, WinZip, o cualquier software similar en Windos. Para usar tar para crear un archivo que incluya todas las bases de datos, cambie la localización en el directorio de datos del maestro, luego ejecute el comando:shell> tar -cvf /tmp/mysql-snapshot.tar .Si quiere que el archivo sólo incluya una base de datos llamada this_db, use este comando:shell> tar -cvf /tmp/mysql-snapshot.tar ./this_dbLuego copie el archivo en el directorio /tmp del servidor esclavo. En esa máquina, cambie la localización al directorio de datos del esclavo, y desempaquete el fichero usando este comando:shell> tar -xvf /tmp/mysql-snapshot.tarPuede no querer replicar la base de datos mysql si el servidor esclavo tiene un conjunto distinto de cuentas de usuario a la existente en el maestro. En tal caso, debe excluírla del archivo. Tampoco necesita incluir ningún fichero de log en el archivo, o los ficheros master.info o relay-log.info files.Mientras el bloqueo de FLUSH TABLES WITH READ LOCK está en efecto, lee el valor del nombre y el desplazamiento del log binario actual en el maestro:mysql > SHOW MASTER STATUS;+---------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+---------------+----------+--------------+------------------+| mysql-bin.003 | 73 | test | manual,mysql |+---------------+----------+--------------+------------------+La columna File muestra el nombre del log, mientras que Position muestra el desplazamiento. En este ejemplo, el valor del log binario es mysql-bin.003 y el desplazamiento es 73. Guarde los valores. Los necesitará más tarde cuando inicialice el servidor. Estos representan las coordenadas de la replicación en que el esclavo debe comenzar a procesar nuevas actualizaciones del maestro.Una vez que tiene los datos y ha guardado el nombre y desplazamiento del log, puede reanudar la actividad de escritura en el maestro:mysql> UNLOCK TABLES;Si está usando tablas InnoDB , debería usar la herramienta InnoDB Hot Backup. Realiza una copia consistente sin bloquear el servidor maestro, y guarda el nombre y desplazamiento del log que se corresponden a la copia para usarlo posteriormente en el esclavo. InnoDB Hot Backup es una herramienta no libre (comercial) que no está

incluída en la distribución de MySQL estándar. Consulte la página web de InnoDB Hot Backup enhttp://www.innodb.com/manual.php para información detallada.Sin la herramienta Hot Backup , la forma más rápida de hacer una copia binaria de los datos de las tablasInnoDB es parar el maestro y copiar los ficheros de datos InnoDB, ficheros de log, y ficheros de definición de tablas (ficheros .frm). Para guardar los nombres de ficheros actual y desplazamientos, debe ejecutar el siguiente comando antes de parar el servidor:mysql> FLUSH TABLES WITH READ LOCK;mysql> SHOW MASTER STATUS;Luego guarde el nombre del log y el desplazamiento desde la salida de SHOW MASTER STATUS como se mostró antes. Tras guardar el nombre del log y el desplazamiento, pare el servidor sin bloquear las tablas para asegurarse que el servidor para con el conjunto de datos correspondiente al fichero de log correspondiente y desplazamiento:shell> mysqladmin -u root shutdownUna alternativa que funciona para tablas MyISAM y InnoDB es realizar un volcado SQL del maestro en lugar de una copia binaria como se describe en la discusión precedente. Para ello, puede usar mysqldump --master-data en su maestro y cargar posteriormente el fichero de volcado SQL en el esclavo. Sin embargo, esto es más lento que hacer una copia binaria.Si el maestro se ha ejecutado previamente sin habilitar --log-bin , el nombre del log y las posiciones mostradas por SHOW MASTER STATUS o mysqldump --master-data están vacíos. En ese caso, los valores que necesita usar posteriormente cuando especifica el fichero de log del esclavo y la posición son una cadena vacía ('') y 4.

4. Asegúrese que la sección [mysqld] del fichero my.cnf en el maestro incluye una opción log-bin . Esta sección debe también tener la opción server-id=master_id , donde master_id debe ser un entero positivo de 1 a 2^32 - 1. Por ejemplo:

5. [mysqld]6. log-bin=mysql-bin

server-id=1Si estas opciones no están presentes, añádalas y reinicie el servidor.

7. Pare el servidor que se vaya a usar como esclavo y añada lo siguiente a su fichero my.cnf :

8. [mysqld]server-id=slave_idEl valor slave_id , como el valor master_id , debe ser un entero positivo de 1 a 2^32 - 1. Además, es muy importante que el ID del esclavo sea diferente del ID del maestro. Por ejemplo:[mysqld]server-id=2Si está preparando varios esclavos, cada uno debe tener un valor de server-id único que difiera del maestro y de cada uno de los otros esclavos. Piense en los valores de server-id como algo similar a las direcciones IP: estos IDs identifican unívocamente cada instancia de servidor en la comunidad de replicación.

Si no especifica un server-id, se usa 1 si no ha definido un master-host, de otro modo se usa 2. Tenga en cuenta que en caso de omisión de server-id, un maestro rechaza conexiones de todos los esclavos, y un esclavo rechaza conectar a un maestro. Por lo tanto, omitir el server-id es bueno sólo para copias de seguridad con un log binario.

9. Si ha hecho una copia de seguridad binara de los datos del maestro, cópielo en el directorio de datos del esclavo antes de arrancar el esclavo. Asegúrese que los privilegios en los ficheros y directorios son correctos. El usuario que ejecuta el servidor MySQL debe ser capaz de leer y escribir los ficheros, como en el maestro.Si hizo una copia de seguridad usando mysqldump, arranque primero el esclavo (consulte el siguiente paso).

10. Arranque el esclavo. Si ha estado replicando préviamente, arranque el esclavo con la opción --skip-slave-start para que no intente conectar inmediatamente al maestro. También puede arrancar el esclavo con la opción --log-warnings (activada por defecto en MySQL 5.0), para obtener más mensajes en el log de errores acerca de problemas (por ejemplo, problemas de red o conexiones). En MySQL 5.0, las conexiones abortadas no se loguean en el log de errores a no ser que el valor sea mayor que 1.

11. Si hace una copia de seguridad de los datos del maestro usando mysqldump, cargue el fichero de volcado en el esclavo:shell> mysql -u root -p < dump_file.sql

12. Ejecute los siguientes comandos en el esclavo, reemplazando los valores de opciones con los valores relevantes para su sistema:

13. mysql> CHANGE MASTER TO14. -> MASTER_HOST='master_host_name',15. -> MASTER_USER='replication_user_name',16. -> MASTER_PASSWORD='replication_password',17. -> MASTER_LOG_FILE='recorded_log_file_name',

-> MASTER_LOG_POS=recorded_log_position;La siguiente tabla muestra la longitud máxima para las opciones de cadenas de caracteres:MASTER_HOST 60MASTER_USER 16MASTER_PASSWORD 32MASTER_LOG_FILE 255

18. Arranque el flujo esclavo:mysql> START SLAVE;

Una vez realizado este procedimiento, el esclavo debe conectar con el maestro y atapar cualquier actualización que haya ocurrido desde que se obtuvieron los datos.Si ha olvidado asignar un valor para server-id en el maestro, los esclavos no son capaces de conectar.Si olvida asignar un valor para server-id en el esclavo, obtiene el siguiente error en el log de errores:Warning: You should set server-id to a non-0 value if master_host is set;

we will force server id to 2, but this MySQL server will not act as a slave.También encuentra mensajes de error en el log de errores del esclavo si no es capaz de replicar por ninguna otra razón.Una vez que un esclavo está replicando, puede encontrar en su directorio de datos un fichero llamadomaster.info y otro llamado relay-log.info. El esclavo usa estos dos ficheros para saber hasta que punto ha procesado el log binario del maestro. No borre o edite estos ficheros, a no ser que realmente sepa lo que hace y entienda las implicaciones. Incluso en tal caso, es mejor que use el comando CHANGE MASTER TO.Nota: El contenido de master.info subedita algunas de las opciones especificadas en línea de comandos o enmy.cnf. Consulte Sección 6.8, “Opciones de arranque de replicación” para más detalles.Una vez que tiene una copia de los datos, puede usarlo para actualizar otros esclavos siguiendo las porciones del procedimiento descrito. No necesita otra muestra de los datos del maestro; puede usar la misma para todos los esclavos.Nota: para la mayor durabilidad y consistencia posible en una inicialización de replicación usando InnoDB con transacciones debe usar innodb_flush_logs_at_trx_commit=1, sync-binlog=1, y innodb_safe_binlog en su fichero my.cnf del maestro.

Replicación y creación de reflejo de la base de datos (SQL Server)

La creación de reflejo de la base de datos se puede usar conjuntamente con la replicación para mejorar la disponibilidad para la base de datos de publicación. La creación de reflejo de la base de datos incluye la creación de dos copias de una sola base de datos que suelen residir en diferentes equipos. En cada momento, solo una copia de la base de datos está disponible para los clientes. Esta copia se conoce como la base de datos principal. Las actualizaciones realizadas por los clientes en la base de datos de la entidad de seguridad se aplican a la otra copia de la base de datos, conocida como la base de datos reflejada. La creación de reflejo incluye la aplicación a la base de datos reflejada del registro de transacciones con todas las inserciones, actualizaciones o eliminaciones efectuadas en la base de datos de la entidad de seguridad.La conmutación por error de replicación en un reflejo se admite totalmente para las bases de datos de publicación, con compatibilidad limitada con las bases de datos de suscripciones. La creación de reflejo de la base de datos no se admite para la base de datos de distribución. Para obtener información sobre la recuperación de una base de datos de distribución o una base de datos de suscripciones sin necesidad de volver configurar la replicación, vea Hacer copias de seguridad y restaurar bases de datos replicadas. Para obtener información sobre la creación de reflejo de la base de datos de suscriptor, vea

Nota

Después de una conmutación por error, la entidad reflejada se convierte en la entidad de seguridad. En este tema, los términos "entidad de seguridad" y "reflejada" siempre hacen referencia a las entidades de seguridad y reflejada originales.

Requisitos y consideraciones para el uso de la replicación con la creación de reflejo de la base de datosSe deben tener en cuenta los siguientes requisitos y consideraciones al utilizar la replicación con la creación de reflejo de la base de datos:

Las entidades de seguridad y reflejada deben compartir un distribuidor.Se recomienda que éste sea un distribuidor remoto, ya que proporciona mayor tolerancia a errores si se produce una conmutación por error imprevista en el publicador.

El publicador y el distribuidor deben serMicrosoft SQL Server 2005 o una versión posterior.Los suscriptores pueden ser de cualquier versión, aunque las suscripciones de extracción de la replicación de mezcla pertenecientes a una versión anterior a SQL Server 2005 no admiten la conmutación por error. En este caso, el agente se ejecuta en el suscriptor y las versiones anteriores del agente no están habilitadas para el reflejo.La replicación en estos suscriptores se reanuda si se produce la conmutación por recuperación de la base de datos reflejada a la de entidad de seguridad.

La replicación admite la creación de reflejo de la base de datos de publicación en la replicación de mezcla y en la replicación transaccional con suscriptores de solo lectura o suscriptores de actualización en cola.No se admiten suscriptores de actualización inmediata, publicadores de Oracle, publicadores en una topología punto a punto ni republicación.

Los metadatos y los objetos que existen fuera de la base de datos, incluidos inicios de sesión, trabajos, servidores vinculados, etc., no se copian en la entidad reflejada.Si se requieren los metadatos y los objetos en la entidad reflejada, se deben copiar manualmente.Para obtener más información, vea Administrar inicios de sesión y trabajos tras la conmutación de roles (creación de reflejo de la base de datos).

Configurar la replicación con la creación de reflejo de la base de datosLa configuración de la replicación y la creación de reflejo de la base de datos implica cinco pasos. Cada paso se describe en detalle en la siguiente sección.

1. Configurar el publicador2. Configurar la creación de reflejo de la base de datos3. Configurar la entidad reflejada de manera que utilice el mismo distribuidor que la

entidad de seguridad4. Configurar los agentes de replicación para la conmutación por error5. Agregar las entidades de seguridad y reflejada al Monitor de replicación

El orden de los pasos 1 y 2 se puede invertir.Para configurar la creación de reflejo de la base de datos para una base de datos de publicación

1. Configure el publicador:a. Se recomienda el uso de un distribuidor remoto.Para obtener más

información acerca de cómo configurar la distribución, vea Configurar la distribución.

b. Se puede habilitar una base de datos para publicaciones transaccionales y de instantáneas y/o para publicaciones de combinación.Para las bases de datos reflejadas que incluirán más de un tipo de publicación, se debe habilitar la base de datos para ambos tipos en el mismo nodo usando sp_replicationdboption.Por ejemplo, puede ejecutar el siguiente procedimiento almacenado en la entidad de seguridad:

c. exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true

d. exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=truePara obtener más información acerca de cómo crear publicaciones, vea Publicar datos y objetos de base de datos.

2. Configurar la creación de reflejo de la base de datos.Para obtener más información, vea Establecer una sesión de creación de reflejo de la base de datos mediante la autenticación de Windows (SQL Server Management Studio) yConfigurar la creación de reflejo de la base de datos (SQL Server).

3. Configurar la distribución para la entidad reflejada.Indique el nombre de la entidad reflejada como el publicador y especifique el mismo distribuidor y la misma carpeta de instantáneas que se utilizan en la entidad de seguridad.Por ejemplo, si está configurando la replicación con procedimientos almacenados, ejecute sp_adddistpublisher en el distribuidor y, a continuación, ejecute sp_adddistributor en la entidad reflejada.Para sp_adddistpublisher:

o Establezca el valor del parámetro @publisher en el nombre de red de la entidad reflejada.

o Establezca el valor del parámetro @working_directory en la carpeta de instantáneas que se utiliza en la entidad de seguridad.

4. Especifique el nombre de la entidad reflejada para el parámetro de agente –PublisherFailoverPartner.Este parámetro es necesario para que los siguientes agentes identifiquen la entidad reflejada después de una conmutación por error:

o Agente de instantáneas (para todas las publicaciones)o Agente de registro del LOG (para todas las publicaciones transaccionales)o Agente de lectura de cola (para las publicaciones transaccionales que

admiten suscripciones de actualización en cola)o Agente de mezcla (para suscripciones de mezcla)o Escucha de replicación de SQL Server (replisapi.dll: para suscripciones de

mezcla sincronizadas mediante sincronización web)o Control ActiveX de mezcla de SQL (para suscripciones de mezcla

sincronizadas con el control)El Agente de distribución y el Control ActiveX de distribución de SQL no tienen este parámetro porque no se conectan al publicador.Los cambios en los parámetros del agente tendrán efecto la próxima vez que se inicie el agente.Si el agente se ejecuta sin interrupción, debe detener y reiniciar el agente.Los parámetros se pueden especificar en perfiles de agente y desde el símbolo del sistema.Para obtener más información, vea:

o Ver y modificar parámetros del símbolo del sistema de los agentes de replicación (SQL Server Management Studio)

o Conceptos de los ejecutables del Agente de replicaciónSe recomienda agregar el parámetro –PublisherFailoverPartner a un perfil de agente y, a continuación, especificar el nombre de la entidad reflejada en el perfil.Por ejemplo, si configura la replicación con procedimientos almacenados:-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.-- Select the profile id of the profile that needs to be updated from the result set.-- In the agent_type column returned by sp_help_agent_profile: -- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.

exec sp_help_agent_profile;

-- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).-- Execute sp_add_agent_parameter in the context of the distribution database.exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';

-- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).-- Execute sp_add_agent_parameter in the context of the distribution database.exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';

5. Agregue las entidades de seguridad y reflejada al Monitor de replicación.Para obtener más información, vea Agregar y quitar publicadores del Monitor de replicación.

Mantener una base de datos de publicación reflejadaEl mantenimiento de una base de datos de publicación reflejada se realiza básicamente de la misma forma que para una base de datos no reflejada, con las siguientes salvedades:

La administración y la supervisión deben tener lugar en el servidor activo.En SQL Server Management Studio, las publicaciones aparecen debajo de la carpeta Publicaciones locales solo para el servidor activo.Por ejemplo, si produce la conmutación por error a la entidad reflejada, las publicaciones se muestran en la entidad reflejada y dejan de aparecer en la entidad de seguridad.Si se produce la conmutación por error de la base de datos a la entidad reflejada, puede que sea necesario actualizar manualmente Management Studioy el Monitor de replicación para que se refleje el cambio.

El Monitor de replicación muestra los nodos del publicador en el árbol de objetos de la entidad de seguridad y reflejada.Si la entidad de seguridad es el servidor activo, la información de publicación solo se mostrará debajo del nodo de la entidad de seguridad en el Monitor de replicación.

Si la entidad reflejada es el servidor activo:o Si se produce un error en un agente, solo se indicará en el nodo de la

entidad de seguridad, no en el nodo de la entidad reflejada.o Si la entidad de seguridad no está disponible, los nodos de la entidad de

seguridad y reflejada muestran listas de publicaciones idénticas.La supervisión debe realizarse en las publicaciones debajo del nodo de la entidad reflejada.

Si se utilizan procedimientos almacenados o Replication Management Objects (RMO) para administrar la replicación en la entidad reflejada, en los casos en que se especifica el nombre del publicador, se debe especificar el nombre de la instancia en la que la base de datos se habilitó para la replicación.Para determinar el nombre correcto, use la funciónpublishingservername.Cuando se crea el reflejo de una base de datos de publicación, los metadatos de la replicación que se encuentran almacenados en la base de datos reflejada son idénticos a los que se encuentran almacenados en la base de datos de la entidad de seguridad.En consecuencia, para las bases de datos de publicación habilitadas para replicación en la entidad de seguridad, el nombre de la instancia del publicador que está almacenado en las tablas del sistema en la entidad reflejada es el nombre de la entidad de seguridad, en lugar del nombre de la entidad reflejada.Esto afecta a la configuración y al mantenimiento de la replicación si se produce la conmutación por error de la base de datos de publicación a la entidad reflejada.Por ejemplo, si se configura la replicación con procedimientos almacenados en la entidad reflejada después de una conmutación por error y se desea agregar una suscripción de extracción a una base de datos de publicación que estaba habilitada en la entidad de seguridad, se debe especificar el nombre de la entidad de seguridad, en lugar del nombre de la entidad reflejada, para el parámetro @publisher de sp_addpullsubscription o de sp_addmergepullsubscription.Si se habilita una base de datos de publicación en la entidad reflejada después de una conmutación por error a dicha entidad, el nombre de la instancia del publicador que está almacenado en las tablas del sistema es el nombre de la entidad reflejada. En este caso, se debe utilizar el nombre de la entidad reflejada para el parámetro @publisher.

Nota

En algunos casos, por ejemplo sp_addpublication, el parámetro @publisher solo se admite para publicadores que no sean de SQL Server. En estos casos, no es relevante para la creación de reflejo de la base de datos de SQL Server.

Para sincronizar una suscripción en Management Studio tras una conmutación por error: sincronice las suscripciones de extracción del suscriptor y sincronice las suscripciones de inserción del publicador activo.

Comportamiento de la replicación si se quita la creación de reflejoTenga en cuenta las siguientes consideraciones si se quita la creación de reflejo de la base de datos de una base de datos publicada:

Si la base de datos de publicación de la entidad de seguridad ya no está reflejada, la replicación continúa funcionando sin variaciones con la entidad de seguridad original.

Si se produce la conmutación por error de la base de datos de publicación de la entidad de seguridad a la entidad reflejada y, por consiguiente, se deshabilita o quita la relación de creación de reflejo, los agentes de replicación no funcionarán con la entidad reflejada.Si la entidad de seguridad se pierde de forma permanente, deshabilite y, a continuación, vuelva a configurar la replicación con la entidad reflejada especificada como publicador.

Si se quita por completo la creación de reflejo de la base de datos, la base de datos reflejada se encontrará en un estado de recuperación y deberá restaurarse para ser funcional.El comportamiento de la base de datos recuperada con respecto a la replicación depende de si se ha especificado la opción KEEP_REPLICATION.Esta opción obliga a la operación de restauración a conservar la configuración de la replicación cuando restaure una base de datos publicada en un servidor distinto del servidor en el que se creó la copia de seguridad.Utilice la opción KEEP_REPLICATION solo cuando la otra base de datos de publicación no esté disponible.Esta opción no es compatible si la otra base de datos de publicación sigue intacta y continúa con la replicación.Para obtener más información acerca de KEEP_REPLICATION, vea RESTORE (Transact-SQL).

Comportamiento del Agente de registro del LOGEn la siguiente tabla se describe el comportamiento del Agente de registro del LOG en los distintos modos de funcionamiento de la creación de reflejo de la base de datos.

Modo operativo Comportamiento del Agente de registro del LOG si la entidad reflejada no está disponible

Modo de seguridad alta con conmutación automática por error

Si la entidad reflejada no está disponible, el Agente de registro del LOG propaga los comandos a la base de datos de distribución.La entidad de seguridad no puede realizar la conmutación por error a la entidad reflejada hasta que la entidad reflejada vuelva a estar en línea e incluya todas las transacciones de la entidad de seguridad.

Modo de alto rendimiento

Si la entidad reflejada no está disponible, la base de datos de la entidad de seguridad se ejecuta de forma expuesta (es decir, sin reflejo).Sin embargo, el Agente de registro del LOG solo replica las transacciones reforzadas en la entidad reflejada.Si se fuerza el servicio y el servidor reflejado asume el rol de la entidad de seguridad, el Agente de registro del LOG trabajará con la entidad reflejada y comenzará a recoger

las transacciones nuevas.Tenga en cuenta que aumentará la latencia de replicación si la entidad reflejada se retrasa con respecto a la entidad de seguridad.

Modo de seguridad alta sin conmutación automática por error

Se garantiza que todas las transacciones confirmadas se refuerzan en disco en la entidad reflejada.El Agente de registro del LOG solo replica las transacciones reforzadas en la entidad reflejada.Si la entidad reflejada no está disponible, la entidad de seguridad no permite que continúe la actividad en la base de datos; por lo tanto, el Agente de registro del LOG no contará con transacciones para replicar.

Replicación de POSTGRE SQL

●Para tener un sistema tolerable a fallas.●Para balancear la carga de trabajo en diversos servidores.●Para aplicaciones de alto consumo en consultas (B.I.)●Para tener un ambiente de pruebas o desarrollo lo más parecido al ambiente de producción.●Muchas otras que se puedan imaginar Características de la replicación interna de PgSQL 9.0Es Streaming Replication Hot Standby●No requiere hardware especial●No requiere de servidores/servicios especiales●No sobrecarga el servidor principal●No requiere de un sistema de resolución de conflictos (al menos no adicionales al que ya implementa la base de datos)●Si se cayera la replicación al menos tendré acceso de lectura●Point-In-Time Recovery, es decir permite recuperar la data al tiempo pasado más cercano donde esta se encuentre bien.●Usa WAL como método de cache, esta técnica permite asegurar que solo las operaciones bien realizadas actualicen la data (atomicidad y durabilidad).●Múltiples servidores maestros/principales●Asegurar que ante una falla el servidor principal nunca va a perder la data●Controlar la replicación a nivel de tablasEl WAL es...Básicamente es un buffer donde se llevan a cabo las operaciones a la data y una vez terminada se pasan al almacenamiento de datos principal, si algo pasara entonces el área de datos permanecerá intacto solo se perderá lo que esta en el WAL.WAL genera segmentos de data de 16mb (configurable) en archivos físicos que tiene páginas de datos de 8kb (configurable).El WAL es...

typedef struct XLogRecord{pg_crc32 xl_crc; /* CRC for this record */XLogRecPtr xl_prev; /* ptr to previous record in log */TransactionId xl_xid; /* xact id */uint32 xl_tot_len; /* total len of entire record */uint32 xl_len; /* total len of rmgr data */uint8 xl_info; /* flag bits, see below */RmgrId xl_rmid; /* resource manager for this record */} XLogRecord;typedef struct XLogRecData{char *data; /* start of rmgr data to include */uint32 len; /* length of rmgr data to include */Buffer buffer; /* buffer associated with data, if any */bool buffer_std; /* buffer has standard pd_lower/pd_upper */struct XLogRecData *next; /* next struct in chain, or NULL */} XLogRecData; typedef struct CheckpointStatsData{TimestampTz ckpt_start_t; /* start of checkpoint */TimestampTz ckpt_write_t; /* start of flushing buffers */TimestampTz ckpt_sync_t; /* start of fsyncs */TimestampTz ckpt_sync_end_t; /* end of fsyncs */TimestampTz ckpt_end_t; /* end of checkpoint */int ckpt_bufs_written; /* # of buffers written */int ckpt_segs_added; /* # of new xlog segments created */int ckpt_segs_removed; /* # of xlog segments deleted */int ckpt_segs_recycled; /* # of xlog segments recycled */} CheckpointStatsData;

El WAL es...Una ventaja del WAL es que puede residir en cualquier directorio y podemos hacer un enlace simbólico al directorio donde debería residir.En caso de que suceda un problema el WAL puede retroceder hacia el pasado hasta el último momento en que todo estuvo ok.El primer paso: indicar donde “copiaremos el WAL”En los archivos de configuración debemos indicar donde vamos a duplicar nuestros WAL files tomaremos en cuenta que debe existir una comunicación en ese file system entre los 2 servidores.Se puede usar NFS para ello, quizás (aún no lo he probado) podría usarse SSHFS como una forma más sencilla.

Para asegurar que se copiarán todas las transacciones haremos que se mantenga un buen numero de segmentos WAL historicamente, pasar data por red tiene una demora importante que debemos tener en cuenta.NFS: * Más complicado de configurar* Más rápido porque funciona a nivel de protocolo más bajo y coordinado con el kernel.* ¿Menos seguro en la transmisión?SSHFS: * Más simple de configurar* Más lento que NFS, 1 a 2, porque funciona en capa más alta de tcp/ip y básicamente es un SCP.* ¿Más seguro en la transmisión?El segundo paso: reconstruir la imagen inicial de la db en el servidor de destino.La Herramienta más popular para esto es Rsync.Rsync trabaja en base a deltas binarios para determinar los cambios bit a bit entre 2 árboles de directorio y los files que este contiene.Se saca un checksum (md5) de los contenidos para verificar contra el espejo que es lo que ha cambiado.En los 2 anteriores pasos mencionados hasta el momento existen algunas ventajas, estamos limitados a replicar únicamente a un solo servidor, podemos realizar esto en varios y en cascada, otra es que podemos hacer esto casi en caliente.Tercer paso: configurar el servidor réplica solo como servidor de consulta.Dado que las transacciones se manejarán en el servidor principal en las réplicas no podemos más que procesar consultas, ambos servicios no pueden escribir en la zona del WAL.Esto es un servidor HOTSTANDBYHOTSTANDBYHotstandby permite a PostgreSQL correr querys solo de consulta, de forma generica el estado Hotstandby permite recuperarse hasta un estado consistente a una db mientras esta sigue atendiendo conexiones.En la replica podemos ejecutar estos tipos de queries:Query access - SELECT, COPY TOCursor commands - DECLARE, FETCH, CLOSEParameters - SHOW, SET, RESETTransaction management commandsBEGIN, END, ABORT, START TRANSACTIONSAVEPOINT, RELEASE, ROLLBACK TO SAVEPOINTEXCEPTION blocks and other internal subtransactions LOCK TABLE, though only when explicitly in one of these modes: ACCESS SHARE, ROW SHARE or ROW EXCLUSIVE.Plans and resources - PREPARE, EXECUTE, DEALLOCATE, DISCARDPlugins and extensions – LOAD

HOTSTANDBY

Uno podría iniciar una transacción pero el sistema nunca le asignará un espacio en el WAL por lo tanto nunca se grabará nadaLos principales problemas que se pueden presentar son:● Locks de Accesos Exclusivos en el servidor principal que bloquean tablas en la réplica.● Borrar tablespace en el servidor principal que crean conflictos con queries que los usan en la réplica.● Borrar una base de datos en el servidor principal y que en la replica existan conexiones a esta db.● Correr un full vacuum mientras el WAL de la réplica aún tiene visible la fila.● El mismo caso del anterior pero un query tiene acceso a las páginas a borrar.

HOTSTANDBYEn la mayoría de los casos el problema genera un delay, este puede ser demasiado grande debido al control de concurrencias por ejemplo:* servidor réplica lanza un query con lock exclusivo sobre una tabla enorme que toma 15” * llega un drop table del servidor primario* servidor réplica sigue procesando el query* servidor primario sigue trabajando normalmente* servidor replica tiene paradas las transacciones replicadas del servidor primario hasta que no acabe el query en la réplica* termina el query en el servidor réplica y por fin aplica los otros cambios en colados* tenemos 15” minutos de retraso si es que no pasa de nuevoPara ello es deseable configurar el tiempo de espera para procesar el WAL y no tener este tipo de problemas, los quieres que sobrepasen este tiempo serán abortados.