El texto original proviene de: https://bohutang.me/2020/08/26/clickhouse-and-friends-mysql-gtid-replication/
Última actualización: 2020-09-03
<El principio de la replicación en tiempo real de MySQL >
Hace unos días ClickHouse lanzó oficialmente v20.8.1.4447-testing (https://github.com/ClickHouse/ClickHouse/releases/tag/v20.8.1.4447-testing), esta versión ya incluye el motor MaterializeMySQL, que está implementado ClickHouse tiene la capacidad de replicar datos MySQL en tiempo real. Los amigos interesados pueden experimentarlo a través del paquete de instalación oficial. Consulte el método de instalación: https://clickhouse.tech/#quick-start. Tenga en cuenta que debe elegir la rama de prueba.
Sincronización basada en el sitio
MaterializeMySQL en la versión de prueba v20.8.1.4447 se sincroniza según el patrón del sitio binlog.
Cada vez que se consume un lote de eventos binlog, la información de ubicación del evento se registrará en el archivo .metadata:
Version: 1
Binlog File: mysql-bin.000002
Binlog Position: 328
Data Version: 1
De esta manera, cuando ClickHouse se inicia nuevamente, informará a MySQL Server de la {'mysql-bin.000002', 328} dos tuplas a través del protocolo, y MySQL enviará datos desde este punto:
s1> ClickHouse 发送 {'mysql-bin.000002', 328} 位点信息给 MySQL
s2> MySQL 找到本地 mysql-bin.000002 文件并定位到 328 偏移位置，读取下一个 event 发送给 ClickHouse
s3> ClickHouse 接收 binlog event 并更新 .metadata位点
Se ve bien, pero hay un problema: si MySQL Server es un clúster (por ejemplo, 1 maestro y 2 esclavos), sirve externamente a través de VIP, y el host de MaterializeMySQL apunta a este VIP. Cuando ocurre el cambio maestro-esclavo del clúster, la tupla de dos {binlog-name, binlog-position} es realmente inexacta, porque el binlog maestro-esclavo en el clúster no es necesariamente el mismo (binlog se puede restablecer).
s1> ClickHouse 发送 {'mysql-bin.000002', 328} 给集群新主 MySQL
s2> 新主 MySQL 发现本地没有 mysql-bin.000002 文件，因为它做过 reset master 操作，binlog 文件是 mysql-bin.000001
... oops ...
Para resolver este problema, desarrollamos el modo de sincronización GTID y abandonamos el modo de sincronización del sitio inseguro. Se ha fusionado upstream # PR13820 (https://github.com/ClickHouse/ClickHouse/pull/13820), la siguiente prueba Versión para experimentar.
Si tiene prisa, puede compilarlo usted mismo o descargarlo e instalarlo a través de ClickHouse Build Check para master-20.9.1 (https://clickhouse-builds.s3.yandex.net/0/2b8ad576cc3892d2d760f3f8b670adf17db0c2a0/clickhouse_build_check/report.html).
Sincronización basada en GTID
GTID es una versión mejorada de la replicación de MySQL, ha sido compatible desde MySQL 5.6 y actualmente es el modo de replicación principal de MySQL.
Asigna una ID y un número de serie únicos a nivel mundial a cada evento. No necesitamos preocuparnos por la topología maestro-esclavo del clúster MySQL, simplemente dígale a MySQL este GTID directamente y el .metadata se convierte en:
Version: 2
Executed GTID: f4aee41e-e36f-11ea-8b37-0242ac110002:1-5
Data Version: 1
f4aee41e-e36f-11ea-8b37-0242ac110002 Es el UUID del host que generó el evento y 1-5es el intervalo de evento sincronizado.
Entonces el proceso se convierte en:
s1> ClickHouse 发送 GTID:f4aee41e-e36f-11ea-8b37-0242ac110002:1-5 给 MySQL
s2> MySQL 根据 GTID:f4aee41e-e36f-11ea-8b37-0242ac110002:1-5 找到本地位点，读取下一个 event 发送给 ClickHouse
s3> ClickHouse 接收 binlog event 并更新 .metadata GTID信息
MySQL abre GTID
Entonces, ¿cómo habilitar GTID en el lado de MySQL? Simplemente agregue los siguientes dos parámetros:
--gtid-mode=ON --enforce-gtid-consistency
Por ejemplo, inicie una ventana acoplable MySQL con GTID habilitado:
docker run -d -e MYSQL_ROOT_PASSWORD=123 mysql:5.7 mysqld --datadir=/var/lib/mysql --server-id=1 --log-bin=/var/lib/mysql/mysql-bin.log --gtid-mode=ON --enforce-gtid-consistency
Precauciones
Una vez habilitado el modo de replicación de GTID, la versión de metadatos cambiará a 2, lo que significa que se informará un error directamente cuando se inicie la versión anterior y la base de datos debe reconstruirse.
para resumir
El motor MaterializeMySQL todavía está en constante iteración. Tenemos un plan preliminar para ello:
Garantía de estabilidad Esta pieza necesita más pruebas y más comentarios de prueba
Optimización de índices Los índices OLTP generalmente no están diseñados para OLAP. En la actualidad, la conversión de índices aún se basa en la estructura de la tabla MySQL y debe ser más inteligente
Observabilidad La información de sincronización actual se puede ver cómodamente en el lado de ClickHouse, similar a MySQL
show slave statusVerificación de la coherencia de los datos Necesidad de proporcionar una forma de verificar la coherencia de los datos de MySQL y ClickHouse
MaterializeMySQL ya es una función de la comunidad y todavía queda mucho trabajo por hacer. Esperando tener más poder para unirse a nosotros, nuestro viaje no se limita a las estrellas y el mar.
Se acabó el texto completo.
Disfruta ClickHouse :)
La clase "MySQL Core Optimization" de Teacher Ye se ha actualizado a MySQL 8.0, escanee el código para comenzar el viaje de la práctica de MySQL 8.0