Comment étendre les champs des grandes tables sous la réplication en cascade MySQL

Extension de champ de grandes tables sous réplication en cascade MySQL

1. Contexte

L'entreprise d'un client a une table d'environ 400 millions de lignes. En raison de l'expansion de l'entreprise, open_id varchar(50) dans la table doit être étendu à varchar(500. ) ).
Lors du changement, essayez de minimiser l'impact sur la bibliothèque principale (de préférence pour ne pas avoir d'impact -> Au final, nous nous sommes efforcés d'avoir une fenêtre de 4 heures).

2. Informations sur la table de base de données

Environnement : Mysql 8.0.22
1 copie maître 1 esclave basée sur Gtid

1 La première question, est-ce une grande table Oui, veuillez regarder l'ibd de cette table

. Le fichier fait 280G + le nombre n'est pas revenu depuis longtemps + J'ai utilisé la base de données en veille pour vérifier et confirmer que le nombre de lignes est > 400 millions

以下语句也可以查看：
show table status from dbname like 'tablename'\G # Rows 的值不准，有时误差有2倍

SELECT a.table_schema,a.table_name,concat(round(sum(DATA_LENGTH/1024/1024)+sum(INDEX_LENGTH/1024/1024),2) ,'MB')total_size,concat(round(sum(DATA_LENGTH/1024/1024),2),'MB') AS data_size,concat(round(sum(INDEX_LENGTH/1024/1024),2),'MB') AS index_size FROM information_schema.TABLES a WHERE a.table_schema = 'dbname' AND a.table_name = 'tablename'; #看下此表的数据量

Puisqu'il s'agit d'une grande table, quelle méthode devons-nous utiliser pour créer des changements ?

3. Sélection de la solution

M ci-dessous représente la bibliothèque principale, S1 est l'esclave 1, S2 est l'esclave 2

Méthode	Avantages	Inconvénients	Faisabilité
DDL en ligne	natif, lors de l'utilisation d'une table temporaire intermédiaire	ALGORITHM=COPY, DML sera bloqué Version recommandée >MySQL5.7	5 étoiles
Gh-ost	Utilisez binlog + replay thread au lieu de trigger	Troisième-. les outils tiers, en fonction de différents paramètres, entraînent des temps d'exécution plus longs	4 étoiles
Pt-osc	La compatibilité des versions est bonne, en utilisant des déclencheurs pour garder les tables principales et secondaires cohérentes	Outils tiers, et là y a plus de restrictions d'utilisation	3 étoiles
M-S1-S2	le temps peut être estimé	réplication en cascade, fonctionnement manuel	1 étoile

Pourquoi n'avons-nous pas choisi les 3 premiers options ?

Sur la base de l'évaluation de la situation réelle, la demande du côté des entreprises cette fois est de Cette table a un trafic professionnel 24 heures sur 24 et n'accepte pas un temps d'indisponibilité commerciale de plus de 4 heures

Méthode OnlineDDL, lorsque l'ALGORITHME =COPY, le point sera bloqué DML (lecture seule), lors de l'opération de renommage final des tables primaire et secondaire (non lisible et inscriptible), jusqu'à ce que DDL soit terminé (le temps requis est incertain).

Il est recommandé de se connecter à la bibliothèque esclave en mode Gh-ost pour la conversion. Ce mode a le moins d'impact sur la bibliothèque principale, et le contrôle de flux peut être défini via des paramètres. La faiblesse fatale de cet outil est que le changement prend trop de temps. Pour une table contenant 400 millions de données, il a fallu 70 heures dans l'environnement de test. Enfin, nous devons également émettre une commande de commutation et supprimer manuellement la table intermédiaire *_del. L'avantage de cette solution est qu'il existe une base de données esclave pour assurer la sécurité des données, donc si vous utilisez une architecture 1 maître 2 esclaves, elle est plus recommandée.

Pt-osc et Gh-ost appartiennent tous deux à des tiers. Le fonctionnement des grandes tables par Pt-osc et OnlineDDL ont un inconvénient commun, à savoir que le coût de la restauration en cas d'échec est très élevé.

S'il s'agit d'une version inférieure telle que MySQL <5.7, elle peut être utilisée. En théorie, OnlineDDL commence à être pris en charge dans MySQL 5.6.7. Le support n'est pas très bon au début, vous pouvez donc choisir en conséquence.

Au final, nous avons choisi la méthode préférée du DBA (xin ku), qui est réalisée sous réplication en cascade M-S1-S2.

4. Comment fonctionner

• Créez une nouvelle bibliothèque esclave S1 et construisez la réplication en cascade M-S1-S2

• Utilisez OnlineDDL pour étendre le champ sur S2 (l'avantage est que pendant la période, le maître de M-S1 jamais affecté)

• Une fois l'expansion terminée, attendez la synchronisation retardée de M-S1-S2 (réduisez la différence de données entre S2 et M et effectuez la vérification des données)

• Supprimez S1 et établissez le relation maître-esclave de M-S2 (laissez S2 continuer à synchroniser les données de M)

• Sauvegardez S2 et restaurez S1, établissez la réplication en cascade M-S2-S1

• L'application s'arrête et attend le maître-esclave les données soient cohérentes (l'avantage est que le temps de synchronisation du volume de données différentielles est très court)

• Au final, S2 devient la bibliothèque maître et S1 est la bibliothèque esclave (l'application doit modifier le front-end informations de connexion)

• L'application effectue une vérification de régression

Le contenu ci-dessus semble très compliqué, mais il s'agit essentiellement de sauvegarde et de récupération. Les lecteurs peuvent considérer cela comme une alternative. Partager les étapes spécifiques ?

环境装备:开启Gtid,注意M,S1 binlog保存时长,磁盘剩余空间大于待变更表的2倍
show global variables like 'binlog_expire_logs_seconds'; # 默认604800
set global binlog_expire_logs_seconds=1209600; # 主库和级联主库都需要设置
1.搭建 1主2从的级联复制，M -> S1 -> S2 ，安装MySQL注意本次环境lower_case_table_names = 0 
2.在S2 上做字段扩容。 预估 10个小时
`参数设置:`
set global slave_type_conversions='ALL_NON_LOSSY'; # 防止复制报错SQL_Errno: 13146，属于字段类型长度不一致无法回放
set global interactive_timeout=144000;set global wait_timeout =144000;
`磁盘IO参数设置:`
set global innodb_buffer_pool_size=32*1024*1024*1024;# 增加buffer_pool 防止Error1206The total number of locks exceeds the lock table size 资源不足
set global sync_binlog=20000;set global innodb_flush_log_at_trx_commit=2;
set global innodb_io_capacity=600000;set global innodb_io_capacity_max=1200000; # innodb_io_capacity需要设置两次
show variables like '%innodb_io%'; # 验证以上设置
screen 下执行:
time mysql -S /data/mysql/3306/data/mysqld.sock -p'' dbname -NBe "ALTER TABLE tablename MODIFY COLUMN open_id VARCHAR(500) NULL DEFAULT NULL COMMENT 'Id' COLLATE 'utf8mb4_bin';"
查看DDL进度:
SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED  FROM performance_schema.events_stages_current;
3.扩容完成后，等待延迟同步M-S1-S2 
数据同步至主从一致,对比主从Gtid
4.移除S1,建立M-S2的主从关系
S1 (可选)
stop slave;
reset slave all;
systemctl stop mysql_3306
S2
stop slave;
reset slave all;
# MASTER_HOST='M主机IP'  
CHANGE MASTER TO
  MASTER_HOST='',
  MASTER_USER='',
  MASTER_PASSWORD=',
  MASTER_PORT=3306,
  MASTER_AUTO_POSITION=1,
  MASTER_CONNECT_RETRY=10;
start slave; (flush privileges;# 验证数据可正常同步)
5.备份S2恢复S1，建立M-S2-S1级联复制
物理备份S2,重做S2->S1 级联主从
rm -rf binlog/*
rm -rf redolog/*
xtrabackup --defaults-file=/data/mysql/3306/my.cnf.3306 --move-back --target-dir=/data/actionsky/xtrabackup_recovery/data
chown -R mysql. data/
chown -R mysql. binlog/*
chown -R mysql. redolog/*
systemctl start mysql_3306
set global gtid_purged='';
reset slave all;
# MASTER_HOST='S2主机IP'  ,已扩容变更完的主机
CHANGE MASTER TO
  MASTER_HOST='',
  MASTER_USER='',
  MASTER_PASSWORD='',
  MASTER_PORT=3306,
  MASTER_AUTO_POSITION=1,
  MASTER_CONNECT_RETRY=10;
`MySQL8.0版本需要在上面语句中添加 GET_MASTER_PUBLIC_KEY=1; #防止 Last_IO_Errno: 2061 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.`
start slave;
6.应用停服，等待主从数据一致
主库停服+可设置read_only+flush privileges，对比主从Gtid
7.最终S2成为主库，S1为从库
应用更改配置连接新主库。
S2上:
stop slave;reset slave all;
set global read_only=0;set global super_read_only=0;
`show master status\G 观察是否有新事务写入`

收尾：还原第2步的参数设置。
set global interactive_timeout=28800;set global wait_timeout =28800;
set global innodb_buffer_pool_size=8*1024*1024*1024;
set global slave_type_conversions='';
set global sync_binlog=1;set global innodb_flush_log_at_trx_commit=1;
set global innodb_io_capacity=2000;set global innodb_io_capacity_max=4000;

Scénario supplémentaire : Test basé sur la capacité d'E/S du disque

Modifiez directement sur la bibliothèque principale et il n'y a pas de trafic :
Scénario 1, le disque est une machine physique NVME, 400 millions de données prend environ 5 heures (performances du disque 1G/s).
Scénario 2, la machine virtuelle dont le disque est un disque mécanique, cette quantité de données prend environ 40 heures (performances du disque 100M/s).

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!