Replicacin en MySQL Aqu hay una breve descripcin de cmo inicializar una replicacin completa de su servidor MySQL.

Asume que quiere replicar todas las bases de datos en el maestro y no tiene una replicacin prviamente configurarla. Necesita parar el servidor maestro brevemente para completar los pasos descritos aqu. Este procedimiento est escrito en trminos de inicializar un esclavo nico, pero puede usarlo para inicializar mltiples esclavos. Mientras este mtodo es el ms 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 ms detalles, consulte Seccin 6.9, Preguntas y respuestas sobre replicacin. Si quiere administrar la inicializacin de una replicacin MySQL, sugerimos que lea este captulo entero y pruebe todos los comandos mencionados enSeccin 13.6.1, Sentencias SQL para el control de servidores maestros ySeccin 13.6.2, Sentencias SQL para el control de servidores esclavos. Tambin debe familiarizarse con las opciones de arranque de replicacin descritas en Seccin 6.8, Opciones de arranque de replicacin. Nota: este procedimiento y algunos de los comandos de replicacin SQL mostrados en secciones posteriores necesitan el privilegio SUPER. 1. Asegrese de que las versiones de MySQL instalado en el maestro y en el esclavo son compatibles segn dice la tabla mostrada en Seccin 6.5, Compatibilidad entre versiones de MySQL con respecto a la replicacin. Idealmente, debe usar la versin ms reciente de MySQL en maestro y servidor. Por favor no reporte bugs hasta que ha verificado que el problema est presente en la ltima versin 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 slo para replicacin (lo que se recomienda), no necesita dar ningn privilegio adicional. (Para informacin sobre preparar cuentas de usuarios y privilegios, consulte Seccin 5.7, Gestin 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 contrasea 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 slo 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 ejecucin 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 ms fcil 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 localizacin en el directorio de datos del maestro, luego ejecute el comando: shell> tar -cvf /tmp/mysql-snapshot.tar . Si quiere que el archivo slo incluya una base de datos llamada this_db, use este comando: shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db Luego copie el archivo en el directorio /tmp del servidor esclavo. En esa mquina, cambie la localizacin al directorio de datos del esclavo, y desempaquete el fichero usando este comando: shell> tar -xvf /tmp/mysql-snapshot.tar Puede 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 exclurla del archivo. Tampoco necesita incluir ningn 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 ms tarde cuando inicialice el servidor. Estos representan las coordenadas de la replicacin 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 , debera 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

4.

5. 6.

7. 8.

includa en la distribucin de MySQL estndar. Consulte la pgina web de InnoDB Hot Backup enhttp://www.innodb.com/manual.php para informacin detallada. Sin la herramienta Hot Backup , la forma ms rpida 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 definicin 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 shutdown Una 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 discusin 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 ms 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 --masterdata estn vacos. En ese caso, los valores que necesita usar posteriormente cuando especifica el fichero de log del esclavo y la posicin son una cadena vaca ('') y 4. Asegrese que la seccin [mysqld] del fichero my.cnf en el maestro incluye una opcin log-bin . Esta seccin debe tambin tener la opcin server-id=master_id , donde master_id debe ser un entero positivo de 1 a 2^32 - 1. Por ejemplo: [mysqld] log-bin=mysql-bin server-id=1 Si estas opciones no estn presentes, adalas y reinicie el servidor. Pare el servidor que se vaya a usar como esclavo y aada lo siguiente a su fichero my.cnf : [mysqld] server-id=slave_id El valor slave_id , como el valor master_id , debe ser un entero positivo de 1 a 2^32 1. Adems, es muy importante que el ID del esclavo sea diferente del ID del maestro. Por ejemplo: [mysqld] server-id=2 Si 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 unvocamente cada instancia de servidor en la comunidad de replicacin.

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 omisin 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 slo para copias de seguridad con un log binario. 9. Si ha hecho una copia de seguridad binara de los datos del maestro, cpielo en el directorio de datos del esclavo antes de arrancar el esclavo. Asegrese 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 prviamente, arranque el esclavo con la opcin --skip-slave-start para que no intente conectar inmediatamente al maestro. Tambin puede arrancar el esclavo con la opcin --log-warnings (activada por defecto en MySQL 5.0), para obtener ms 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 TO 14. -> 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 mxima para las opciones de cadenas de caracteres: MASTER_HOST 60 MASTER_USER 16 MASTER_PASSWORD 32 MASTER_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 actualizacin 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.

Tambin encuentra mensajes de error en el log de errores del esclavo si no es capaz de replicar por ninguna otra razn. 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 lnea de comandos o enmy.cnf. Consulte Seccin 6.8, Opciones de arranque de replicacin para ms 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 inicializacin de replicacin usando InnoDB con transacciones debe usar innodb_flush_logs_at_trx_commit=1, syncbinlog=1, y innodb_safe_binlog en su fichero my.cnf del maestro. Replicacin y creacin de reflejo de la base de datos (SQL Server) La creacin de reflejo de la base de datos se puede usar conjuntamente con la replicacin para mejorar la disponibilidad para la base de datos de publicacin. La creacin de reflejo de la base de datos incluye la creacin 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 creacin de reflejo incluye la aplicacin 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 conmutacin por error de replicacin en un reflejo se admite totalmente para las bases de datos de publicacin, con compatibilidad limitada con las bases de datos de suscripciones. La creacin de reflejo de la base de datos no se admite para la base de datos de distribucin. Para obtener informacin sobre la recuperacin de una base de datos de distribucin o una base de datos de suscripciones sin necesidad de volver configurar la replicacin, vea Hacer copias de seguridad y restaurar bases de datos replicadas. Para obtener informacin sobre la creacin de reflejo de la base de datos de suscriptor, vea Nota Despus de una conmutacin por error, la entidad reflejada se convierte en la entidad de seguridad. En este tema, los trminos "entidad de seguridad" y "reflejada" siempre hacen referencia a las entidades de seguridad y reflejada originales.

Requisitos y consideraciones para el uso de la replicacin con la creacin de reflejo de la base de datos Se deben tener en cuenta los siguientes requisitos y consideraciones al utilizar la replicacin con la creacin 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 conmutacin por error imprevista en el publicador. El publicador y el distribuidor deben serMicrosoft SQL Server 2005 o una versin posterior.Los suscriptores pueden ser de cualquier versin, aunque las suscripciones de extraccin de la replicacin de mezcla pertenecientes a una versin anterior a SQL Server 2005 no admiten la conmutacin por error. En este caso, el agente se ejecuta en el suscriptor y las versiones anteriores del agente no estn habilitadas para el reflejo.La replicacin en estos suscriptores se reanuda si se produce la conmutacin por recuperacin de la base de datos reflejada a la de entidad de seguridad. La replicacin admite la creacin de reflejo de la base de datos de publicacin en la replicacin de mezcla y en la replicacin transaccional con suscriptores de solo lectura o suscriptores de actualizacin en cola.No se admiten suscriptores de actualizacin inmediata, publicadores de Oracle, publicadores en una topologa punto a punto ni republicacin. Los metadatos y los objetos que existen fuera de la base de datos, incluidos inicios de sesin, 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 ms informacin, vea Administrar inicios de sesin y trabajos tras la conmutacin de roles (creacin de reflejo de la base de datos). Configurar la replicacin con la creacin de reflejo de la base de datos La configuracin de la replicacin y la creacin de reflejo de la base de datos implica cinco pasos. Cada paso se describe en detalle en la siguiente seccin. 1. Configurar el publicador 2. Configurar la creacin de reflejo de la base de datos 3. Configurar la entidad reflejada de manera que utilice el mismo distribuidor que la entidad de seguridad 4. Configurar los agentes de replicacin para la conmutacin por error 5. Agregar las entidades de seguridad y reflejada al Monitor de replicacin El orden de los pasos 1 y 2 se puede invertir. Para configurar la creacin de reflejo de la base de datos para una base de datos de publicacin 1. Configure el publicador: a. Se recomienda el uso de un distribuidor remoto.Para obtener ms informacin acerca de cmo configurar la distribucin, vea Configurar la distribucin.

b. Se puede habilitar una base de datos para publicaciones transaccionales y de instantneas y/o para publicaciones de combinacin.Para las bases de datos reflejadas que incluirn ms de un tipo de publicacin, 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=true Para obtener ms informacin acerca de cmo crear publicaciones, vea Publicar datos y objetos de base de datos. 2. Configurar la creacin de reflejo de la base de datos.Para obtener ms informacin, vea Establecer una sesin de creacin de reflejo de la base de datos mediante la autenticacin de Windows (SQL Server Management Studio) yConfigurar la creacin de reflejo de la base de datos (SQL Server). 3. Configurar la distribucin para la entidad reflejada.Indique el nombre de la entidad reflejada como el publicador y especifique el mismo distribuidor y la misma carpeta de instantneas que se utilizan en la entidad de seguridad.Por ejemplo, si est configurando la replicacin con procedimientos almacenados, ejecute sp_adddistpublisher en el distribuidor y, a continuacin, ejecute sp_adddistributor en la entidad reflejada.Para sp_adddistpublisher: o Establezca el valor del parmetro @publisher en el nombre de red de la entidad reflejada. o Establezca el valor del parmetro @working_directory en la carpeta de instantneas que se utiliza en la entidad de seguridad. 4. Especifique el nombre de la entidad reflejada para el parmetro de agente PublisherFailoverPartner.Este parmetro es necesario para que los siguientes agentes identifiquen la entidad reflejada despus de una conmutacin por error: o Agente de instantneas (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 actualizacin en cola) o Agente de mezcla (para suscripciones de mezcla) o Escucha de replicacin de SQL Server (replisapi.dll: para suscripciones de mezcla sincronizadas mediante sincronizacin web) o Control ActiveX de mezcla de SQL (para suscripciones de mezcla sincronizadas con el control) El Agente de distribucin y el Control ActiveX de distribucin de SQL no tienen este parmetro porque no se conectan al publicador. Los cambios en los parmetros del agente tendrn efecto la prxima vez que se inicie el agente.Si el agente se ejecuta sin interrupcin, debe detener y reiniciar el agente.Los parmetros se pueden especificar en perfiles de agente y desde el smbolo del sistema.Para obtener ms informacin, vea:

Ver y modificar parmetros del smbolo del sistema de los agentes de replicacin (SQL Server Management Studio) o Conceptos de los ejecutables del Agente de replicacin Se recomienda agregar el parmetro PublisherFailoverPartner a un perfil de agente y, a continuacin, especificar el nombre de la entidad reflejada en el perfil.Por ejemplo, si configura la replicacin 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.
o

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 replicacin.Para obtener ms informacin, vea Agregar y quitar publicadores del Monitor de replicacin. Mantener una base de datos de publicacin reflejada El mantenimiento de una base de datos de publicacin reflejada se realiza bsicamente de la misma forma que para una base de datos no reflejada, con las siguientes salvedades: La administracin y la supervisin 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 conmutacin 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 conmutacin por error de la base de datos a la entidad reflejada, puede que sea necesario actualizar manualmente Management Studioy el Monitor de replicacin para que se refleje el cambio. El Monitor de replicacin 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 informacin de publicacin solo se mostrar debajo del nodo de la entidad de seguridad en el Monitor de replicacin.

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 idnticas.La supervisin 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 replicacin 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 replicacin.Para determinar el nombre correcto, use la funcinpublishingservername. Cuando se crea el reflejo de una base de datos de publicacin, los metadatos de la replicacin que se encuentran almacenados en la base de datos reflejada son idnticos a los que se encuentran almacenados en la base de datos de la entidad de seguridad.En consecuencia, para las bases de datos de publicacin habilitadas para replicacin 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 configuracin y al mantenimiento de la replicacin si se produce la conmutacin por error de la base de datos de publicacin a la entidad reflejada.Por ejemplo, si se configura la replicacin con procedimientos almacenados en la entidad reflejada despus de una conmutacin por error y se desea agregar una suscripcin de extraccin a una base de datos de publicacin 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 parmetro @publisher de sp_addpullsubscription o de sp_addmergepullsubscription. Si se habilita una base de datos de publicacin en la entidad reflejada despus de una conmutacin 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 parmetro @publisher. Nota En algunos casos, por ejemplo sp_addpublication, el parmetro @publisher solo se admite para publicadores que no sean de SQL Server. En estos casos, no es relevante para la creacin de reflejo de la base de datos de SQL Server.

Para sincronizar una suscripcin en Management Studio tras una conmutacin por error: sincronice las suscripciones de extraccin del suscriptor y sincronice las suscripciones de insercin del publicador activo.

Comportamiento de la replicacin si se quita la creacin de reflejo Tenga en cuenta las siguientes consideraciones si se quita la creacin de reflejo de la base de datos de una base de datos publicada: Si la base de datos de publicacin de la entidad de seguridad ya no est reflejada, la replicacin contina funcionando sin variaciones con la entidad de seguridad original. Si se produce la conmutacin por error de la base de datos de publicacin de la entidad de seguridad a la entidad reflejada y, por consiguiente, se deshabilita o quita la relacin de creacin de reflejo, los agentes de replicacin no funcionarn con la entidad reflejada.Si la entidad de seguridad se pierde de forma permanente, deshabilite y, a continuacin, vuelva a configurar la replicacin con la entidad reflejada especificada como publicador. Si se quita por completo la creacin de reflejo de la base de datos, la base de datos reflejada se encontrar en un estado de recuperacin y deber restaurarse para ser funcional.El comportamiento de la base de datos recuperada con respecto a la replicacin depende de si se ha especificado la opcin KEEP_REPLICATION.Esta opcin obliga a la operacin de restauracin a conservar la configuracin de la replicacin cuando restaure una base de datos publicada en un servidor distinto del servidor en el que se cre la copia de seguridad.Utilice la opcin KEEP_REPLICATION solo cuando la otra base de datos de publicacin no est disponible.Esta opcin no es compatible si la otra base de datos de publicacin sigue intacta y contina con la replicacin.Para obtener ms informacin acerca de KEEP_REPLICATION, vea RESTORE (Transact-SQL). Comportamiento del Agente de registro del LOG En la siguiente tabla se describe el comportamiento del Agente de registro del LOG en los distintos modos de funcionamiento de la creacin de reflejo de la base de datos. Modo operativo Modo de seguridad alta con conmutacin automtica por error Comportamiento del Agente de registro del LOG si la entidad reflejada no est disponible Si la entidad reflejada no est disponible, el Agente de registro del LOG propaga los comandos a la base de datos de distribucin.La entidad de seguridad no puede realizar la conmutacin por error a la entidad reflejada hasta que la entidad reflejada vuelva a estar en lnea e incluya todas las transacciones de la entidad de seguridad. 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

Modo de rendimiento

alto

las transacciones nuevas. Tenga en cuenta que aumentar la latencia de replicacin si la entidad reflejada se retrasa con respecto a la entidad de seguridad. Modo de seguridad alta sin conmutacin automtica 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 contine la actividad en la base de datos; por lo tanto, el Agente de registro del LOG no contar con transacciones para replicar.

Replicacin 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 ms parecido al ambiente de produccin. Muchas otras que se puedan imaginar Caractersticas de la replicacin interna de PgSQL 9.0 Es 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 resolucin de conflictos (al menos no adicionales al que ya implementa la base de datos) Si se cayera la replicacin al menos tendr acceso de lectura Point-In-Time Recovery, es decir permite recuperar la data al tiempo pasado ms cercano donde esta se encuentre bien. Usa WAL como mtodo de cache, esta tcnica permite asegurar que solo las operaciones bien realizadas actualicen la data (atomicidad y durabilidad). Mltiples servidores maestros/principales Asegurar que ante una falla el servidor principal nunca va a perder la data Controlar la replicacin a nivel de tablas El WAL es... Bsicamente 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 fsicos que tiene pginas 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 simblico al directorio donde debera 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 configuracin debemos indicar donde vamos a duplicar nuestros WAL files tomaremos en cuenta que debe existir una comunicacin en ese file system entre los 2 servidores. Se puede usar NFS para ello, quizs (an no lo he probado) podra usarse SSHFS como una forma ms sencilla.

Para asegurar que se copiarn 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: * Ms complicado de configurar * Ms rpido porque funciona a nivel de protocolo ms bajo y coordinado con el kernel. * Menos seguro en la transmisin? SSHFS: * Ms simple de configurar * Ms lento que NFS, 1 a 2, porque funciona en capa ms alta de tcp/ip y bsicamente es un SCP. * Ms seguro en la transmisin? El segundo paso: reconstruir la imagen inicial de la db en el servidor de destino. La Herramienta ms 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 rplica solo como servidor de consulta. Dado que las transacciones se manejarn en el servidor principal en las rplicas no podemos ms que procesar consultas, ambos servicios no pueden escribir en la zona del WAL. Esto es un servidor HOTSTANDBY HOTSTANDBY Hotstandby 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 TO Cursor commands - DECLARE, FETCH, CLOSE Parameters - SHOW, SET, RESET Transaction management commands BEGIN, END, ABORT, START TRANSACTION SAVEPOINT, RELEASE, ROLLBACK TO SAVEPOINT EXCEPTION 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, DISCARD Plugins and extensions LOAD HOTSTANDBY

Uno podra iniciar una transaccin pero el sistema nunca le asignar un espacio en el WAL por lo tanto nunca se grabar nada Los principales problemas que se pueden presentar son: Locks de Accesos Exclusivos en el servidor principal que bloquean tablas en la rplica. Borrar tablespace en el servidor principal que crean conflictos con queries que los usan en la rplica. 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 rplica an tiene visible la fila. El mismo caso del anterior pero un query tiene acceso a las pginas a borrar. HOTSTANDBY En la mayora de los casos el problema genera un delay, este puede ser demasiado grande debido al control de concurrencias por ejemplo: * servidor rplica lanza un query con lock exclusivo sobre una tabla enorme que toma 15 * llega un drop table del servidor primario * servidor rplica 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 rplica * termina el query en el servidor rplica y por fin aplica los otros cambios en colados * tenemos 15 minutos de retraso si es que no pasa de nuevo Para 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 sern abortados.