Le texte original provient de: https://bohutang.me/2020/08/26/clickhouse-and-friends-mysql-gtid-replication/
Dernière mise à jour: 2020-09-03
<Le principe de la réplication en temps réel de MySQL >
Il y a quelques jours, ClickHouse a officiellement publié v20.8.1.4447-testing (https://github.com/ClickHouse/ClickHouse/releases/tag/v20.8.1.4447-testing), cette version inclut déjà le moteur MaterializeMySQL, qui est implémenté ClickHouse a la capacité de répliquer les données MySQL en temps réel. Les amis intéressés peuvent en faire l'expérience via le package d'installation officiel. Reportez-vous à la méthode d'installation: https://clickhouse.tech/#quick-start. Notez que vous devez choisir la branche de test.
Synchronisation basée sur le site
MaterialiseMySQL dans la version v20.8.1.4447-testing est synchronisé en fonction du modèle de site binlog.
Chaque fois qu'un lot d'événements binlog est consommé, les informations de localisation de l'événement seront enregistrées dans le fichier .metadata:
Version: 1
Binlog File: mysql-bin.000002
Binlog Position: 328
Data Version: 1
De cette façon, lorsque ClickHouse est redémarré, il informera MySQL Server du {'mysql-bin.000002', 328} deux-tuple via le protocole, et MySQL enverra des données à partir de ce point:
s1> ClickHouse 发送 {'mysql-bin.000002', 328} 位点信息给 MySQL
s2> MySQL 找到本地 mysql-bin.000002 文件并定位到 328 偏移位置，读取下一个 event 发送给 ClickHouse
s3> ClickHouse 接收 binlog event 并更新 .metadata位点
Cela a l'air bien, mais il y a un problème: si MySQL Server est un cluster (par exemple, 1 maître et 2 esclaves), il sert en externe via VIP, et l'hôte de MaterializeMySQL pointe vers ce VIP. Lorsque le commutateur maître-esclave du cluster se produit, le double-tuple {binlog-name, binlog-position} est en fait inexact, car le binlog maître-esclave du cluster n'est pas nécessairement le même (binlog peut être réinitialisé).
s1> ClickHouse 发送 {'mysql-bin.000002', 328} 给集群新主 MySQL
s2> 新主 MySQL 发现本地没有 mysql-bin.000002 文件，因为它做过 reset master 操作，binlog 文件是 mysql-bin.000001
... oops ...
Pour résoudre ce problème, nous avons développé le mode de synchronisation GTID et abandonné le mode de synchronisation de site non sécurisé. Il a été fusionné en amont # PR13820 (https://github.com/ClickHouse/ClickHouse/pull/13820), le test suivant Version à découvrir.
Si vous êtes pressé, vous pouvez le compiler vous-même ou le télécharger et l'installer via ClickHouse Build Check pour master-20.9.1 (https://clickhouse-builds.s3.yandex.net/0/2b8ad576cc3892d2d760f3f8b670adf17db0c2a0/clickhouse_build_check/report.html).
Synchronisation basée sur GTID
GTID est une version améliorée de la réplication MySQL. Il est pris en charge depuis MySQL 5.6 et est actuellement le mode de réplication principal de MySQL.
Il attribue un identifiant et un numéro de série uniques à chaque événement. Nous n'avons pas besoin de nous soucier de la topologie maître-esclave du cluster MySQL, il suffit de dire à MySQL ce GTID directement, et le .metadata devient:
Version: 2
Executed GTID: f4aee41e-e36f-11ea-8b37-0242ac110002:1-5
Data Version: 1
f4aee41e-e36f-11ea-8b37-0242ac110002 Est l'UUID de l'hôte qui a généré l'événement et 1-5est l'intervalle d'événements synchronisés.
Ainsi, le processus devient:
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 ouvre GTID
Alors, comment activer GTID du côté MySQL? Ajoutez simplement les deux paramètres suivants:
--gtid-mode=ON --enforce-gtid-consistency
Par exemple, démarrez un docker MySQL avec GTID activé:
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
Précautions
Une fois le mode de réplication GTID activé, la version des métadonnées passe à 2, ce qui signifie qu'une erreur sera signalée directement au démarrage de l'ancienne version et que la base de données doit être reconstruite.
Pour résumer
Le moteur MaterialiseMySQL est toujours en itération constante. Nous avons un plan préliminaire pour cela:
Garantie de stabilité Cette pièce nécessite plus de tests et plus de retours d'essai
Optimisation de l'index Les index OLTP ne sont généralement pas conçus pour OLAP. À l'heure actuelle, la conversion d'index repose toujours sur la structure de la table MySQL et doit être plus intelligente
Observabilité Les informations de synchronisation actuelles peuvent être facilement visualisées du côté ClickHouse, similaire à MySQL
show slave statusVérification de la cohérence des données Besoin de fournir un moyen de vérifier la cohérence des données MySQL et ClickHouse
MaterialiseMySQL est déjà une fonctionnalité communautaire, et il reste encore beaucoup de travail à faire. Dans l'attente de plus de puissance pour nous rejoindre, notre voyage ne se limite pas aux étoiles et à la mer.
Le texte intégral est terminé.
Profitez de ClickHouse :)
La classe "MySQL Core Optimization" du professeur Ye a été mise à niveau vers MySQL 8.0, scannez le code pour commencer le voyage de la pratique de MySQL 8.0