MySQL no limita la cantidad de esclavos que puede conectar al servidor maestro en una topología de replicación. Sin embargo, a medida que aumenta la cantidad de esclavos, afectarán los recursos del maestro porque los registros binarios deberán servirse a diferentes esclavos que trabajen a diferentes velocidades. Si la rotación de datos en el maestro es alta, el servicio de registros binarios por sí solo podría saturar la interfaz de red del maestro.
Una solución clásica para este problema es implementar un servidor binlog, un servidor proxy intermedio que se encuentra entre el maestro y sus esclavos. El servidor binlog se configura como esclavo del maestro y, a su vez, actúa como maestro para el conjunto original de esclavos. Recibe eventos de registro binario del maestro, no aplica estos eventos, pero los envía a todos los demás esclavos. De esta manera, la carga en el maestro se reduce enormemente y, al mismo tiempo, el servidor binlog sirve los binlogs de manera más eficiente a los esclavos, ya que no tiene que realizar ningún otro procesamiento del servidor de base de datos.
Ripple es un servidor binlog de código abierto desarrollado por Pavel Ivanov. Una publicación de blog de Percona, titulada MySQL Ripple:The First Impression of a MySQL Binlog Server, brinda una muy buena introducción a la implementación y el uso de Ripple. Tuve la oportunidad de explorar Ripple con más detalle y quería compartir mis observaciones a través de esta publicación.
1. Compatibilidad con la replicación basada en GTID
Ripple solo admite el modo GTID y no la replicación basada en archivos y posiciones. Si su maestro se ejecuta en modo no GTID, obtendrá este error de Ripple:
Error al leer el paquete:Error al leer el paquete del servidor:El subproceso del remitente de replicación no puede iniciarse en modo AUTO_POSITION:este servidor tiene GTID_MODE =APAGADO en lugar de ENCENDIDO.
Puede especificar Server_id y UUID para el servidor de ripple usando las opciones de línea cmd: -ripple_server_id y -ripple_server_uuid
Ambos son parámetros opcionales y, si no se especifican, Ripple usará el server_id=112211 predeterminado y el uuid se generará automáticamente.
2. Conexión al maestro usando el usuario y la contraseña de replicación
Mientras se conecta al maestro, puede especificar el usuario y la contraseña de replicación usando las opciones de la línea de comandos:
-ripple_master_user y -ripple_master_password
3. Punto final de conexión para el servidor Ripple
Puede usar las opciones de la línea de comando -ripple_server_ports y -ripple_server_address para especificar los puntos finales de conexión para el servidor Ripple. Asegúrese de especificar el nombre de host accesible a la red o la dirección IP de su servidor Ripple como -rippple_server_address. De lo contrario, de forma predeterminada, Ripple se vinculará a localhost y, por lo tanto, no podrá conectarse a él de forma remota.
4. Configuración de esclavos para el servidor Ripple
Puedes usar el comando CHANGE MASTER TO para conectar tus esclavos para replicar desde el servidor Ripple.
Para asegurarse de que Ripple pueda autenticar la contraseña que usa para conectarse, debe iniciar Ripple especificando la opción -ripple_server_password_hash
Por ejemplo, si inicia el servidor Ripple con el comando:
rippled -ripple_datadir=./binlog_server -ripple_master_address= <master ip> -ripple_master_port=3306 -ripple_master_user=repl -ripple_master_password='password' -ripple_server_ports=15000 -ripple_server_address='172.31.23.201' -ripple_server_password_hash='EF8C75CB6E99A0732D2DE207DAEF65D555BDFB8E'
puede usar el siguiente comando CHANGE MASTER TO para conectarse desde el esclavo:
CHANGE MASTER TO master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’
Tenga en cuenta que el hash de contraseña especificado para el servidor Ripple corresponde a la contraseña de texto utilizada en el comando CHANGE MASTER TO. Actualmente, Ripple no se autentica en función de los nombres de usuario y acepta cualquier nombre de usuario que no esté vacío siempre que la contraseña coincida.
Explorando MySQL Binlog Server - RippleClick To Tweet5. Administración del servidor Ripple
Es posible monitorear y administrar el servidor Ripple utilizando el protocolo MySQL desde cualquier cliente MySQL estándar. Hay un conjunto limitado de comandos compatibles que puede ver directamente en el código fuente en la página de mysql-ripple GitHub.
Algunos de los comandos útiles son:
SELECT @@global.gtid_executed;– Para ver el GTID SET del servidor Ripple en función de sus registros binarios descargados.STOP SLAVE;– Para desconectar el servidor Ripple del maestro.START SLAVE;– Para conectar el servidor Ripple al maestro.
Problemas conocidos y sugerencias para mejorar
1. No vi una opción para configurar un canal de replicación SSL desde un servidor Ripple al maestro
Como resultado de esto, el servidor Ripple no podrá conectarse a un maestro que requiera conexiones encriptadas. Intentar conectarse resultará en el error:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Failed to connected to host: <Hosname>, port: 3306, err: Failed to connect: Connections using insecure transport are prohibited while --require_secure_transport=ON.
2. No pude hacer que el servidor Ripple funcionara con la opción de semisincronización
Inicié el servidor Ripple usando la opción -ripple_semi_sync_slave_enabled=true
Al conectarlo, el maestro pudo detectar el servidor Ripple como un esclavo habilitado para semisincronización.
mysql> show status like 'rpl%';
------------------------------------------------------
| Variable_name | Value |
------------------------------------------------------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | ON |
| Rpl_semi_sync_slave_status | OFF |
------------------------------------------------------
Sin embargo, intentar ejecutar una transacción en modo semisincronizado esperó rpl_semi_sync_master_timeout, que fue 180000
mysql> create database d12;
Query OK, 1 row affected (3 min 0.01 sec)
Pude ver que la sincronización parcial se apagó en el maestro:
mysql> show status like 'rpl%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | OFF |
| Rpl_semi_sync_slave_status | OFF |
+--------------------------------------------+-------+
Fragmento correspondiente de los registros de errores de mysql:
2020-03-21T10:05:56.000612Z 52 [Note] Start binlog_dump to master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:56.000627Z 52 [Note] Start semi-sync binlog_dump to slave (server_id: 112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000010, pos: 350), semi-sync up to file , position 4.
2020-03-21T10:08:55.874044Z 2 [Note] Semi-sync replication switched OFF.
Hay un problema reportado en líneas similares aquí en la página de MySQL Ripple Github.
3. Problema al usar la replicación paralela para los esclavos del servidor Ripple
Vi que el subproceso SQL en el esclavo a menudo se detenía con el error:
Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name /mysql_data/relaylogs/relay-log.000005, position 27023962 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly.
El análisis del registro de retransmisión y la posición anterior reveló que el 'número de secuencia' de la transacción en este punto se restableció a 1. Rastreé la causa de una rotación binlog que ocurría en el maestro originario. Por lo general, para los esclavos directos, hay un evento de rotación debido al cual los registros de retransmisión también rotarían en función de la rotación del registro binario maestro. Mi evaluación es que tales condiciones pueden detectarse y el restablecimiento del número de secuencia puede manejarse mediante subprocesos paralelos. Pero cuando el número de secuencia cambia sin la rotación de los registros de retransmisión, vemos que fallan los subprocesos paralelos.
Esta observación se informa como el problema:falla del subproceso paralelo esclavo al sincronizar desde el servidor binlog #26
4. La utilidad mysqlbinlog no funciona en los registros binarios producidos por el servidor Ripple
Intentar ejecutar la utilidad mysqlbinlog en el registro binario resultó en el error:
ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 43, event_type: -106
Este problema surge aquí:No se pueden abrir los archivos de registro binarios con la utilidad mysqlbinlog. #25
El autor lo reconoce como un problema conocido. Siento que sería útil admitir esta utilidad con fines de depuración.
Ese es el informe por ahora de mi prueba rápida. Planeo actualizar esta publicación de blog a medida que encuentre más hallazgos en Ripple. En general, encontré que es simple y fácil de usar y tiene el potencial de convertirse en un estándar para servidores binlog en entornos MySQL.
|
