En este artículo, vamos a echar un vistazo a la migración de la replicación tradicional a GTID,
discutiremos cómo hacerlo completamente en línea. Primero, analicemos algunas opciones de configuración relacionadas con GTID. El modo GTID determina si el servidor usa GTID o no, esto no solo afecta el inicio de sesión binario de replicación porque los registros binarios tendrán GTID en ellos. La opción de hacer cumplir la consistencia de GTID garantiza que el servidor solo permita declaraciones que sean seguras para ejecutar en modo GTID. Las declaraciones que no son seguras de ejecutar son como crear una tabla como selección, hay algunas más en su mayoría, para el valor de gtid_owned pueden monitorear los GTID en las transacciones en curso. Esto es muy útil cuando están desactivando los GTID en línea.
Hablemos de algunos y, para ser exactos, es solo una variable de estado relacionada con GTID. ONGOING_ANONYMOUS_TRANSACTION_ COUNT es la contraparte de la propiedad de GTID, pero en caso de migración como ONGOING_ANONYMOUS_TRANSACTION_COUNT, se denomina transacción anónima porque no tiene un identificador que es el GTID.
Todas las operaciones deben realizarse en uno de los nodos en la topología de replicación y, finalmente, en todos los nodos. La mejor práctica es hacer el esclavo primero y el maestro, pero en el caso de muchas operaciones, el orden realmente no importa siempre que se lleven a cabo en cada instancia de la topología de replicación.
En este entorno, tengo tres máquinas virtuales, dos de ellas son bases de datos y una de ellas es una máquina sysbench para generar tráfico, así que comencemos.
Maestro:192.168.66.5
Esclavo: 192.168.66.7
En el nodo sysbench, ejecutemos el comando preparado para crear una base de datos sysbench, puede simplemente copiar y pegar desde abajo.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password= password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare
En el nodo sysbench, se ejecuta una carga de trabajo contra el maestro que estábamos ejecutando durante la duración de la tarea.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --rate=10 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run
Iniciemos el cliente MySQL en todos los nodos, todos los nodos de la base de datos. Revisemos la lista de procesos mostrados en el maestro para que pueda ver que esto se ha estado ejecutando aquí.
mysql> show processlist; +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 2350 | Waiting on empty queue | NULL | | 8 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 15 | syncstndby | 192.168.66.7:47894 | NULL | Binlog Dump | 156 | Master has sent all binlog to slave; waiting for more updates | NULL | | 17 | sbtest_user | 192.168.66.6:38130 | sbtest | Sleep | 0 | | NULL | | 18 | sbtest_user | 192.168.66.6:38132 | sbtest | Sleep | 1 | | NULL | | 19 | sbtest_user | 192.168.66.6:38134 | sbtest | Sleep | 0 | | NULL | | 20 | sbtest_user | 192.168.66.6:38136 | sbtest | Sleep | 0 | | NULL | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ 7 rows in set (0.00 sec)
De acuerdo, de ahora en adelante trabajaremos primero con el bálsamo y el maestro.
Entonces, primero estableceremos enforce_gtid_consistency ='warn' en esclavo, a esclavo maestro.
Esclavo 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Maestro 192.168.66.5
set global enforce_gtid_consistency = 'warn';
hemos terminado aquí y vamos a comprobar el error de MySQL ver el registro de errores esto debería estar bien; no verá ningún error en el registro de errores. Los siguientes pasos son ejecutar set global enforce_gtid_consistency='on' en todas partes y luego verificar la flecha nuevamente.
Esclavo 192.168.66.7
set global enforce_gtid_consistency='on';
Maestro 192.168.66.5
set global enforce_gtid_consistency='on';
Entonces, el siguiente paso es configurar global gtid_mode='off_permissive'; así que nuevamente iniciaré el cliente MySQL y lo configuraré. Y luego revisamos el registro de errores
Esclavo 192.168.66.7
set global gtid_mode='off_permissive';
Maestro 192.168.66.5
set global gtid_mode='off_permissive';
En cada servidor estableceremos el gtid_mode=’on_permissive’; para que generemos transacciones GTID en este punto.
Esclavo 192.168.66.7
set global gtid_mode='on_permissive';
Maestro 192.168.66.5
set global gtid_mode='on_permissive';
Entonces, está configurado en todas partes. Revisemos los registros de errores
Muy bien, ahora comprobaremos si alguno de los nodos tiene transacciones anónimas en curso porque si las tiene, cuando configuramos gtid_mode='on', el servidor ya no acepta transacciones anónimas y obtendremos errores.
Esclavo 192.168.66.7
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.22 sec)
Maestro 192.168.66.5
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.04 sec)
Ambos servidores no tienen lo que significa que estamos listos para activar los GTID. Activaré gtid_mode =on.
Maestro 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Esclavo 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Ahora en los esclavos, necesitamos reiniciar la replicación para usar master-auto-position=1
Esclavo 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Entonces, qué hace esto, este "cambio maestro" aquí, si el subproceso salve ya estaba configurado, entonces si el comando cambiar maestro no toca algún parámetro, simplemente se dejará en el valor actual.
Verifiquemos mostrar el estado del esclavo en los esclavos y mostrar el estado del maestro en el maestro. todo debería estar funcionando bien.
mysql> show salve status\G; mysql> show master status;
Ahora la migración está hecha:
Como sabemos, ninguna actualización es exitosa si no tiene un plan de reversión, para revertir, haga clic en el enlace a continuación para leer el siguiente artículo.
Retroceder a la replicación tradicional desde GTID
