暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / Mysql主从复制架构实战（四）之clone篇

Mysql主从复制架构实战（四）之clone篇

踱岚视角 2024-09-22
3

一、导读

1.1、认识clone

MySQL 的 Clone 插件是一个强大的功能，首次引入于 MySQL 8.0.17 版本。简单来说，Clone Plugin 是一款物理克隆数据工具，它能够帮助我们快速、高效地克隆或复制数据库，极大地简化了数据库迁移、备份和恢复的过程，让我们在处理大量数据时更加得心应手。本篇文章我们一起来学习下如何使用克隆插件。

1.2、clone使用场景

（1） 快速构建测试环境：在开发和测试环境中快速创建与生产环境数据一致的数据库副本，以进行功能测试、性能测试等。

（2）灾难恢复：在数据库发生故障时，可以快速从备份或另一个健康实例克隆数据，以减少恢复时间和业务中断。

（3）数据库迁移：在升级硬件、切换服务器时，使用克隆插件可以快速迁移数据而无需长时间的停机。

（4）水平扩展：在数据库需要增加读取能力时，可以快速克隆数据库到新的服务器上，作为只读从库。

（5）数据库物理备份：克隆插件可以用于构建本地或远程的热备节点，以提高数据的可用性和容错能力。

1.3、clone原理及方式

  克隆插件的工作原理是创建存储在InnoDB中的 schema、table、tablespaces 和 data dictionary metadata的物理快照。这个快照实际上是一个完整的数据目录，MySQL克隆插件可以使用这个目录来配置并恢复一个 MySQL 服务器。

使用克隆插件，用户可以执行本地克隆和远程克隆两种操作：

（1）本地克隆：将数据从启动克隆操作的 MySQL 服务器克隆到该服务器主机上的指定目录下。

（2）远程克隆：涉及到本地 MySQL 服务器（接收方）和远程 MySQL 服务器（发送方），克隆的数据通过网络从发送方传输到接收方。默认情况下，远程克隆操作会删除接收方数据目录中的现有数据，并用克隆的新数据替换。

1.4、clone使用限制

（1）DDL阻塞与兼容性：在早期版本中，克隆操作期间会阻塞源服务器（Donor）上的所有 DDL 操作，但从 MySQL 8.0.27 开始，克隆命令不再阻塞 Donor 上的 DDL 操作。克隆操作要求源和目标MySQL 服务器版本兼容，通常不允许跨大版本克隆。直至最近更新（如MySQL 8.0.37），小版本间的克隆限制有所放宽，但仍需注意版本兼容性。

（2）存储引擎限制：克隆操作仅支持InnoDB表，对于其他存储引擎的表，只会克隆其表结构而不会复制数据。

（3）配置与日志不复制：克隆插件不会复制 Donor服务器的配置参数和二进制日志（Binlog）设置，这意味着目标实例需要独立配置。

（4）操作系统与网络限制：

Ø捐赠者和接受者必须运行在相同的操作系统上，并且在某些情况下，要求网络连接直接而不通过MySQL Router。

Ø指定的 Donor 端口不能是X Protocol端口。

（5）字符集与排序规则：源和目标 MySQL 服务器必须具有相同的字符集和排序规则。

二、环境规划

2 

2.1、操作系统

Linux ubuntu2204 5.15.0-119-generic #129-Ubuntu SMP  Fri Aug 2 19:25:20 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

注：主从库尽量保持一致。

2.2、数据库版本

mysql  Ver  8.0.39-0ubuntu0.22.04.1 for Linux on x86_64 ((Ubuntu))

注：主从库尽量保持一致。

2.3、存储规划

项目

项目值

备注

数据库配置文件目录

/etc/mysql

按实际调整

数据库数据存储目录

/var/lib/mysql

按实际调整

数据库日志文件目录

/var/log/mysql

按实际调整

数据库启动脚本目录

/etc/systemd/system

/etc/init.d

注：主从库尽量保持一致。

2.4、IP地址

服务器

主机名

IP地址

端口号

备注

主库

Master

192.168.56.18

3306

按实际调整

从库

Slave

192.168.56.19

3306

按实际调整

2.5、主从复制数据库初始化方式

本次采用clone方式 ，当然也可以通过xtrabackup物理备份，mysqldump逻辑导出，然后在从库上进行还原的方式进行主从复制初始化工作。

在前续的文章中会逐一介绍。

2.6、主从复制机制

本次采用基于row的模式对主库进行同步复制到备库。

当然也可以通过statement、mixed等复制方式进行主从同步，在后续的文章中会逐一介绍。

2.7、主从复制实现方式

本文采用基于GTID方式，当然也可以基于binlog和position的方式来实现，前面的文章中已经介绍。

2.8、主从复制模式

本次采用默认的复制模式，异步复制，主服务器提交事务后立即返回，而不等待从服务器确认。

当然也可以设置为半同步复制，完全同步复制模式，在后续的文章中会逐一介绍。

2.9、数据库参数

参数名

主库

从库

备注

basedir




datadir




character-set-server

utf8mb4

utf8mb4


lower-case-table-names

1

1


default_authentication_plugin

mysql_native_password

mysql_native_password


server-id

1

2


log-bin

mysql-bin

mysql-bin


binlog-ignore

sys,mysql,

information_schema,performance_schema

sys,mysql,

information_schema,performance_schema

可逗号分隔，也可写多条

binlog-do-db

mydb

mydb

多数据库写多条

replication-do-table




replication-ignore-table

格式:库名.表名

格式:库名.表名

多表写多条

binlog_format

row

row


relay-log

mysql-relay

mysql-relay


log-error

/var/log/mysql/error.log

/var/log/mysql/error.log


port

3306

3306


expire_logs_days

14

14


slow_query_log

1

1


slow_query_log_file

/var/log/mysql/mysql-slow.log

/var/log/mysql/mysql-slow.log


long_query_time

2

2


max_binlog_size

100M

100M


read-only

0

1


gtid-mode

on

on


enforce-gtid-consistency

true

true


plugin-load-add

mysql_clone.so

mysql_clone.so


注：上表红色标识参数为必填。

三、主从搭建详细操作步骤

3 

3.1、主库侧数据库参数设置

3.1.1、非在线模式

按照上表设置数据库参数：

重启数据库服务生效：systemctlrestart mysql

3.1.2、在线模式配置

配置之前，GTID相关参数如上图所示。

3.1.2.1、检查主库是否有不支持GTID的操作

set global enforce_gtid_consistency=warn;

 

让服务器在正常工作负载下运行一段时间并监控错误日志，最好包含一天负载最高的时间段，有条件建议观察2-3天。如果此步骤导致错误日志中出现任何警告，需要调整应用程序，使其仅使用与GTID兼容的功能，并且不能生成与GTID相关的任何警告。这是一个重要步骤，在进行下一步之前，必须确保错误日志中未出现警告。

3.1.2.2、设置GTID相关参数

set global enforce_gtid_consistency=true;

set global gtid_mode=off_permissive;

set global gtid_mode=on_permissive;

set global gtid_mode=on;

 

enforce-gtid-consistency启用后，MySQL服务器通过仅允许执行使GTID安全的语句来强制GTID一致性。在启用基于GTID的复制之前，必须将此选项设置为true。enforce_gtid_consistency的可配置值为：

  • false：允许事务违反GTID一致性。

  • true：不允许事务违反GTID一致性。

  • warn：允许事务违反GTID一致性，但在这种情况下会生成警告。

enforce_gtid_consistency仅在语句进行二进制日志记录时生效。如果在服务器上禁用了二进制日志记录，或者由于过滤器删除了语句而未将语句写入二进制日志，则不会对未记录的语句检查或强制执行GTID一致性。

联机设置gtid_mode时，只能基于OFF、OFF_PERMISSIVE、ON_PERMISSIVE、ON顺序一次改变一步。例如，如果gtid_mode当前设置为OFF_PERMISSIVE，则可以更改为OFF或ON_PERMISSIVE，但不能直接更改为ON，否则会报以下错误：

完成配置之后，GTID相关数据配置如下：

3.1.2.3、将GTID和clone相关参数写入配置文件

enforce_gtid_consistency=true

gtid_mode=on

plugin-load-add=mysql_clone.so

3.2、从库侧数据库参数设置

3.2.1、非在线模式

3.2.2、在线模式配置

操作步骤同3.1.2章节。

3.3、主从侧安装clone插件

3.3.1、确认主从侧clone插件是否安装

SELECT PLUGIN_NAME, PLUGIN_STATUS

  FROM  INFORMATION_SCHEMA.PLUGINS

 WHERE  PLUGIN_NAME = 'clone';

 

3.3.2、主从侧安装clone插件

INSTALL PLUGIN clone SONAME 'mysql_clone.so';

3.4、主库侧创建同步专属账号并授权

CREATE USER 'slave'@'%' IDENTIFIED WITH  mysql_native_password BY 'mysql123456';

GRANT REPLICATION SLAVE,replication  client  ON *.* TO 'slave'@'%';

flush privileges;

注：以上账户如果已经存在，则本步骤直接跳过，复用复制用户。

3.5、主从库侧创建clone专属账号并授权

create user 'clone_user'@'%' identified by 'mysql123456';

grant BACKUP_ADMIN on *.* to 'clone_user'@'%';

grant CLONE_ADMIN on *.* to 'clone_user'@'%';   

grant SYSTEM_VARIABLES_ADMIN on *.* to 'clone_user'@'%';

flush privileges;

注：在本文中需要给clone_user授予SYSTEM_VARIABLES_ADMIN权限，否则在从库克隆时会报错；

3.6、从库侧对主库进行clone

3.6.1、从库侧使用克隆用户登录数据库

mysql -uclone_user -p

3.6.2、从库侧设置克隆源

#将clone_valid_donor_list设置为主库

SET GLOBAL clone_valid_donor_list = '192.168.56.18:3306';

3.6.3、从库侧执行克隆

CLONE INSTANCE FROM  'clone_user'@'192.168.56.18':3306 IDENTIFIED BY 'mysql123456';

 

通过日志可以观察到，在执行克隆时，会先将从库本地的数据目录清空，请确保本地数据目录没有重要数据，可以清空，否则将导致本地数据丢失。克隆完成后，从库MySQL实例自动重启。

3.6.4、克隆过程中状态监控

SELECT STATE, ERROR_NO, ERROR_MESSAGE FROM performance_schema.clone_status;
复制
SELECT STAGE, STATE, END_TIME FROM performance_schema.clone_progress;
复制
 
复制

3.7、从库执行同步配置

change master to  master_host='192.168.56.18',master_user='slave',master_password='mysql123456',  master_auto_position = 1;

 

master_host为主服务器的ip；

master_user为连接主服务器的用户名；

master_password为连接主服务器的密码；

master_auto_position表示使用gtid模式进行复制。

 

3.8、从库侧开启同步slave进程

start slave;

3.9、从库侧查看slave状态

show slave status\G;

 

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

都为Yes则代表配置成功。

四、已有主从切换到GTID模式操作步骤

4 

如果已经在未开启GITD的情况下配置了主从复制，可以联机将复制模式修改为GTID以及自动定位。由于整个过程不需要停止MySQL实例，这种方式适合在生产环境中使用。开始前确保MySQL服务器满足以下前提条件：

  • 复制拓扑中的所有服务器都必须使用MySQL 5.7.6或更高版本。除非拓扑中的所有服务器都使用此版本，否则无法在任何单个服务器上联机启用GTID事务。

  • 所有服务器的gtid_mode默认设置为OFF。

以下过程可以随时暂停，之后再恢复，这使得该过程具有容错能力。如果过程中出现任何不相关的错误，可以先暂停过程解决问题，然后再从停止的地方继续。但至关重要的一点是，在继续下一步之前必须完成之前的步骤。联机改为GTID复制的步骤如下。

4.1、在线配置GTID参数

在主从架构所涉及的数据库上分别执行：

 

1、set global enforce_gtid_consistency=warn;

保证所有操作都与GTID兼容，并且确保错误日志中没有GTID的相关警告。如果出现警告，操作先暂停，故障排出后再继续后续步骤；

2、set global enforce_gtid_consistency=true;   --同上

3、set global gtid_mode=off_permissive;   --同上

4、set global gtid_mode=on_permissive;   --同上

5、确认主从所涉及数据库状态变量ongoing_anonymous_transaction_count为0，使用以下语句查看：show status like  'ongoing_anonymous_transaction_count';

6、如果二进制日志还用于复制以外的其它目的（如基于时间点的恢复等），需要在执行flush  logs后备份二进制日志文件。包含GTID事务的二进制日志在下一步执行之后无法使用。完成此步后，确保拓扑中的任何位置都不存在GTID事务。

7、set global gtid_mode=on;

4.2、从库上配置同步复制

在主从架构所有从库上分别执行：

 

1、stop slave;

2、change master to master_auto_position = 1;

3、start slave;

4.3、GTID参数持久化配置

在主从架构所有数据库库上分别执行：

 

在每台服务器上，将gtid-mode = on和enforce_gtid_consistency=true添加到my.cnf。

五、数据同步测试

5 

5.1、在主库侧mydb创建一个test表

use mydb;

create table test(id int);

5.2、在从库侧查看同步情况

use mydb;

show tables;

5.3、在主库侧给表mydb.test插入记录

use mydb;

insert into test(id) values(1);

insert into test(id) values(2);

insert into test(id) values(3);

insert into test(id) values(4);

select count(1) from test;

commit;

5.4、在从库侧确认mydb.test记录同步情况

use mydb;

select count(1) from test;

5.5、再次查看主从库同步情况

5.5.1、主库侧

show master status\G;

5.5.2、从库侧

show slave status\G;


mysqlmysql主从配置mysql创建数据库数据库服务器数据库
文章转载自踱岚视角，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论