Las bases de datos pueden fallar sin previo aviso, ya sea por un bloqueo causado por un error de software o por los componentes de hardware subyacentes. La nube aporta otra dimensión al problema, debido a la naturaleza efímera de los recursos informáticos y de almacenamiento. Para aislar nuestra infraestructura de base de datos de estas fallas, construimos redundancia en nuestros sistemas. Si una instancia deja de estar disponible, un sistema en espera debería poder asumir la carga de trabajo y continuar desde allí. La replicación es un método bien conocido y ampliamente adoptado para crear copias redundantes de una base de datos maestra.
En esta publicación, vamos a comparar la funcionalidad de replicación en los dos sistemas de bases de datos más populares del planeta (según db-engines):Oracle y MySQL. Veremos específicamente la replicación lógica de Oracle 12c y MySQL 5.7. Ambas tecnologías ofrecen sistemas de reserva confiables para descargar cargas de trabajo de producción y ayudar en caso de desastre. Echaremos un vistazo a sus diferentes arquitecturas, analizaremos los pros y los contras y seguiremos los pasos sobre cómo configurar la replicación con Oracle y MySQL.
Arquitectura Oracle Data Guard:cómo funciona
Oracle Data Guard asegura alta disponibilidad, protección de datos y recuperación ante desastres de sus datos. Probablemente sea la primera opción de Oracle DBA para replicar datos. La tecnología se introdujo en 1990 (versión 7.0) con una aplicación esencial de registros de archivo en bases de datos en espera. Data Guard evolucionó a lo largo de los años y ahora proporciona un conjunto completo de servicios que crean, mantienen, administran y monitorean bases de datos en espera.
Data Guard mantiene bases de datos en espera como copias de la base de datos de producción. Si la base de datos principal deja de responder, Data Guard puede cambiar cualquier función de reserva a producción, lo que genera tiempo de inactividad. Data Guard se puede utilizar para técnicas de copia de seguridad, restauración y clúster para proporcionar un alto nivel de protección y disponibilidad de datos.
Data Guard es una tecnología Ship Redo/Apply Redo, "redo" es la información necesaria para recuperar transacciones. Una base de datos de producción conocida como base de datos primaria difunde rehacer a una o más réplicas denominadas bases de datos en espera. Cuando se realiza una inserción o actualización en una tabla, el escritor de registro captura este cambio en un registro de archivo y lo replica en el sistema de reserva. Las bases de datos en espera están en una fase continua de recuperación, verificando y aplicando rehacer para mantener la sincronización con la base de datos principal. Una base de datos en espera también se volverá a sincronizar automáticamente si se desconecta temporalmente de la principal debido a cortes de energía, problemas de red, etc.
Servicios de red de Oracle Data Guard Los servicios de transporte de rehacer de Data Guard regulan la transmisión de rehacer desde la base de datos principal a la base de datos en espera. El proceso LGWR (escritor de registro) envía los datos de rehacer a uno o más procesos de servidor de red (LNS1, LSN2, LSN3, ... LSNn). LNS está leyendo desde el búfer de rehacer en el SGA (área global compartida) y pasa la redo a Oracle Net Services para transmitir a la base de datos en espera. Puede elegir los atributos LGWR:modo síncrono (LogXptMode ='SYNC') o modo asíncrono (LogXptMode ='ASYNC'). Con tal arquitectura, es posible entregar los datos de rehacer a varias bases de datos en espera o usarlos con Oracle RAC (Real Application Cluster). El proceso del servidor de archivos remoto (RFS) recibe la rehacer de LNS y la escribe en un archivo normal llamado archivo de registro de rehacer en espera (SRL).
Hay dos tipos principales de Oracle Data Guard. Bases de datos físicas con aplicación de rehacer y bases de datos en espera lógicas con aplicación de SQL.
Arquitectura de Oracle Dataguard Logical Replication La aplicación de SQL requiere más procesamiento que la aplicación de rehacer, el proceso primero lee la SRL y "mina" la rehacer convirtiéndola en registros de cambios lógicos, y luego genera transacciones de SQL antes de aplicar el SQL a la base de datos en espera. Hay más partes móviles, por lo que requiere más CPU, memoria y E/S, luego se aplica la rehacer.
El principal beneficio de "SQL apply" es que la base de datos está abierta para lectura y escritura, mientras que el proceso de aplicación está activo.
Incluso puede crear vistas e índices locales. Esto lo hace ideal para herramientas de informes. La base de datos en espera no tiene que ser una copia uno a uno de su base de datos principal y, por lo tanto, puede que no sea la mejor candidata para propósitos de recuperación ante desastres.
Las características clave de esta solución son:
- Una base de datos en espera que se abre para lectura y escritura mientras la aplicación de SQL está activa
- Posible bloqueo de modificación de datos que mantiene el SQL aplicar
- Capaz de ejecutar actualizaciones continuas de la base de datos
Hay inconvenientes. Oracle utiliza un registro complementario de índice/restricción única o clave principal para reconocer lógicamente una fila modificada en la base de datos lógica en espera. Cuando se habilita el registro complementario de clave principal y restricción única/índice en toda la base de datos, cada instrucción UPDATE también escribe los valores de columna necesarios en el registro de rehacer para identificar de forma única la fila modificada en la base de datos lógica en espera. Oracle Data Guard admite la replicación en cadena, que aquí se denomina "cascada", sin embargo, no es habitual debido a la complejidad de la configuración.
Oracle recomienda que agregue una clave principal o un índice único no nulo a las tablas de la base de datos principal, siempre que sea posible, para asegurarse de que SQL Apply pueda aplicar de manera eficiente actualizaciones de datos de rehacer a la base de datos lógica en espera. Esto significa que no funciona en ninguna configuración, es posible que deba modificar su aplicación.
Arquitectura Oracle Golden Gate:cómo funciona
Con Data Guard, a medida que se modifican los bloques en la base de datos, se agregan registros al registro de rehacer. Luego, según el modo de replicación que esté ejecutando, estos registros se copiarán inmediatamente en el modo de espera o se extraerán para los comandos SQL y se aplicarán. Golden Gate funciona de una manera diferente.
Golden Gate solo replica los cambios después de que se confirma la transacción, por lo que si tiene una transacción de ejecución prolongada, la replicación puede demorar un tiempo. El "proceso de extracción" de Golden Gate mantiene los cambios transaccionales en la memoria.
Otra gran diferencia es que Oracle Golden Gate permite el intercambio y la manipulación de datos a nivel de transacción entre múltiples plataformas heterogéneas. No solo está limitado a la base de datos Oracle. Le brinda la flexibilidad de extraer y replicar registros de datos seleccionados, cambios transaccionales y cambios en DDL (lenguaje de definición de datos) en una variedad de topologías.
Arquitectura de Oracle Golden Gate El flujo típico de Golden Gate muestra datos de base de datos nuevos y modificados que se capturan de la base de datos de origen. Los datos capturados se escriben en un archivo llamado registro de origen. Luego, una bomba de datos lee el rastro, lo envía a través de la red y el proceso Collector lo escribe en un archivo de rastro remoto. La función de entrega lee el rastro remoto y actualiza la base de datos de destino. Cada uno de los componentes es administrado por el proceso Manager.
Replicación lógica de MySQL:cómo funciona
La replicación en MySQL existe desde hace mucho tiempo y ha ido evolucionando a lo largo de los años. Hay diferentes formas de habilitar la replicación de MySQL, incluida la replicación de grupo, los clústeres de Galera, "maestro a esclavo" asíncrono. Para comparar la arquitectura de Oracle con la de MySQL, nos centraremos en los formatos de replicación, ya que es la base para todos los tipos de replicación.
En primer lugar, los diferentes formatos de replicación corresponden al formato de registro binario especificado en el archivo de configuración my.cnf. Independientemente del formato, los registros siempre se almacenan de forma binaria, no se pueden ver con un editor normal. Hay tres tipos de formato:basado en filas, basado en declaraciones y mixto. Mixto es la combinación de los dos primeros. Echaremos un vistazo a las declaraciones y las filas.
Basado en declaraciones:en este caso, estas son las consultas escritas. No todas las declaraciones que modifican datos (como las declaraciones INSERT DELETE, UPDATE y REPLACE) se pueden replicar mediante la replicación basada en declaraciones. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS(), etc. no se replicarán.
Basado en filas:en este caso, se trata de cambios en los registros. Todos los cambios se pueden replicar. Esta es la forma más segura de replicación. Desde 5.7.7, es la opción predeterminada.
Ahora echemos un vistazo a lo que sucede debajo del capó cuando la replicación está habilitada.
Arquitectura de replicación MySQL En primer lugar, la base de datos maestra escribe los cambios en un archivo llamado registro binario o binlog. Escribir en el registro binario suele ser una actividad ligera porque las escrituras se almacenan en búfer y son secuenciales. El archivo de registro binario almacena datos que un esclavo de replicación procesará más tarde, la actividad del maestro no depende de ellos. Cuando comience la replicación, mysql activará tres subprocesos. Uno en el maestro, dos en el esclavo. El maestro tiene un hilo, llamado hilo de volcado, que lee el registro binario del maestro y lo entrega al esclavo.
En el esclavo, un proceso llamado subproceso IO se conecta al maestro, lee los eventos de registro binario del maestro a medida que ingresan y los copia en un archivo de registro local llamado registro de retransmisión. El segundo proceso esclavo, el subproceso SQL, lee eventos de un registro de retransmisión almacenado localmente en el esclavo de replicación y luego los utiliza.
MySQL admite la replicación encadenada, que es muy fácil de configurar. Los esclavos que también son maestros deben ejecutarse con los parámetros --log-bin y --log-slave-update.
Para verificar el estado de la replicación y obtener información sobre los subprocesos, ejecute en el esclavo:
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 339
Relay_Log_Space: 938
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-8
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)Configuración de la replicación lógica de Data Guard en Oracle
-
Crear una base de datos física en espera
Para crear una base de datos en espera lógica, primero debe crear una base de datos en espera física y luego hacer la transición a una base de datos en espera lógica.
-
Detener la aplicación de rehacer en la base de datos física en espera
Es necesario detener Redo Apply para evitar la aplicación de cambios.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Preparar la base de datos principal para admitir una base de datos lógica en espera
Cambie el atributo VALID_FOR en el LOG_ARCHIVE_DEST_1 original y agregue LOG_ARCHIVE_DEST_3 para la base de datos lógica.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLECrear un diccionario en los datos de rehacer
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Convertir a una base de datos lógica en espera
Para continuar aplicando datos de rehacer a la base de datos física en espera hasta que esté lista para convertirse en una base de datos lógica en espera, emita la siguiente instrucción SQL:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Ajuste los parámetros de inicialización para la base de datos lógica en espera
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Abrir la base de datos lógica en espera
SQL> ALTER DATABASE OPEN RESETLOGS;Verifique que la base de datos lógica en espera funcione correctamente
vista de v$data_guard_stats
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalvista v$logstdby_process
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
Estos son los pasos necesarios para crear la replicación lógica de Oracle Data Guard. Las acciones serán ligeramente diferentes si realiza esta operación con un conjunto de compatibilidad no predeterminado o bases de datos que se ejecutan en un entorno Oracle RAC.
Configurar la replicación de MySQL
-
Configure la base de datos maestra. Establezca server_id único, especifique diferentes registros de replicación –log-basename (MariaDB), active el registro binario. Modifique el archivo my.cnf con la siguiente información.
log-bin server_id=1 log-basename=master1Inicie sesión en la base de datos maestra y otorgue al usuario de replicación el acceso a los datos maestros.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Inicie ambos servidores con los GTID habilitados.
gtid_mode=ON enforce-gtid-consistency=true -
Configure el esclavo para usar el posicionamiento automático basado en GTID.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Si desea agregar esclavo a maestro con datos, entonces necesita hacer una copia de seguridad y restaurarla en el servidor esclavo.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlInicie sesión en la base de datos esclava y ejecute:
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;
