一、导读
Mysql主从部署的方式有很多种，最常见的方法就是用mysqldump对主库进行逻辑导出到从库进行恢复。
1.1、mysqldump方式缺点
1.1.1、主库需要锁表
这就意味着这期间主库不能做修改的操作（在做导出的时候需要停止相关的接口和应用，对于一些小业务可能没影响，但如果是繁忙的业务，就是相当于停止服务，不能在线搭建主从架构；
1.1.2、备份恢复耗时长
但是当数据量超过20G的时候，整个过程就相当慢。曾经用这种方法导一个70G的数据库，在使用的是高端存储的情况下，导出花费了50分钟，导入更是需要花费更长时间。
1.2、Percona提供了xtrabackup开源备份工具
可以快速且无锁表地进行mysql的备份并且记录相应的log信息，特点如下：
•备份过程快速、可靠；
•备份过程不会打断正在执行的事务；
•能够基于压缩等功能节约磁盘空间和流量；
•自动实现备份检验；
•还原速度快。
1.3、xtrabackup使用场景
•对已有生产库构建主从架构：主库不能停机；
• 主库数据量比较大：可以快速进行备份；
• 主库生产环境本地空间不太充足：可以边备份、边压缩、边传输、边解压，这样可以不占用主库本地磁盘空间，直接通过管道将备份文件传输到从库环境中。
1.4、xtrabackup使用限制
•XtraBackup社区版本主要支持MyISAM、InnoDB、CSV、MRG_MYISAM四种存储引擎的表。其他存储引擎的表不会被备份，如果数据库中存在非支持的存储引擎表，XtraBackup会打印警告信息。
MySQL版本：XtraBackup
8.0及以后版本主要支持MySQL 8.0及以上版本。这是因为MySQL
8.0在数据字典、redo log等方面与之前的版本不兼容。
XtraBackup版本：不同版本的XtraBackup可能支持不同的MySQL版本和特性。例如，XtraBackup 8.0.26新增了对MyRocks存储引擎的支持，但不支持TokuDB引擎。
1.5、大体流程
二、环境规划
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、主从复制数据库初始化方式
本次采用xtraBackup对主库进行物理备份，然后在从库上进行还原的方式进行主从复制初始化工作。
当然也可以通过mysqldump进行主库逻辑导出，然后在从库上进行还原的方式进行主从复制初始化工作。
也可以通过clone技术在线搭建主从复制环境。
在后续的文章中会逐一介绍。
2.6、主从复制机制
本次采用基于row的模式对主库进行同步复制到备库。
当然也可以通过statement、mixed、GTID等复制方式进行主从同步，在后续的文章中会逐一介绍。
2.7、主从复制模式
本次采用默认的复制模式，异步复制，主服务器提交事务后立即返回，而不等待从服务器确认。
当然也可以设置为半同步复制，完全同步复制模式，在后续的文章中会逐一介绍。
2.8、主从库侧部署xtrabackup软件
2.8.1、下载
链接地址：https://www.percona.com/downloads/XtraBackup/
本次下载percona-xtrabackup-8.0.35-31版本。
2.8.2、安装
dpkg -i percona-xtrabackup-80_8.0.35-31-1.jammy_amd64.deb |
本次使用封装好的deb包（不同平台不一样）安装，当然也可以使用二进制代码编译安装。
注：主从库服务器都需要提前安装好。
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 |
三、配置步骤
3.1、主库侧按照上表进行数据库参数设置
3.2、从库侧按照上表进行数据库参数设置
3.3、主库侧创建同步专属账号并授权
CREATE USER 'slave'@'%' IDENTIFIED WITH
mysql_native_password BY 'mysql123456'; GRANT REPLICATION SLAVE,replication client ON *.* TO 'slave'@'%'; flush privileges; |
3.4、从库侧数据库关闭
从库：systemctl stop mysql |
3.5、对主库进行备份
xtrabackup --backup --compress --compress-threads=8
--target-dir=/home/duolan/test/ --user=root --password='123456'
--host=192.168.56.18 --port=3306 --compress 表示采用压缩方式 --target-dir 表示备份文件存放目录，注意操作系统用户要有读写权限 |
以下是产生的备份文件：
3.6、将备份文件打包并拷贝至从库
3.6.1、备份文件打包
tar cvzfp test.tar.gz test |
3.6.2、将打包文件拷贝至从库服务器
scp test.tar.gz root@192.168.56.19:/root/test |
3.7、在从库上进行备份文件解压缩
tar xvzp test.tar.gz |
以上步骤3.5——>3.7是常见的操作步骤，需要占用主库服务器本地磁盘空间，可以在主库服务器上使用以下命令行一次性完成上述任务，且不占用主库服务器本地空间：
xtrabackup --user=root --password=123456
--stream=xbstream --backup --parallel=10 |lz4|ssh root@192.168.56.19 'cat
|lz4 -d|xbstream --parallel=10 -x -C root/test' 通过流式备份，结合管道，直接将备份文件流传输到从库主机，真正做到边备份、边传输、解压，一次性完成上述操作，非常高效。 |
执行完毕之后，可以直接在从库主机/root/test目录下看到以下文件：
3.8、在从库侧执行备份文件prepare预处理
xtrabackup --prepare --target-dir=/root/test 在进行数据库备份后，备份文件可能处于不一致的状态，因为备份过程中数据库可能正在进行写操作。--prepare命令的作用是将备份文件恢复到一个一致的状态，以便可以用于数据库的恢复。 具体来说，它会执行以下操作： 应用事务日志：将备份过程中未完成的事务进行回滚或提交，以确保数据库的一致性。 恢复数据文件：修复可能在备份过程中损坏的数据文件，使其可以被数据库服务器正确读取。 在使用增量备份时，需要将多个增量备份与一个基础备份进行合并。首先，对基础备份进行--prepare操作，然后依次对每个增量备份进行--prepare操作，并将它们合并到基础备份中，最终得到一个完整的、一致的备份集，可以用于数据库的恢复。 --target-dir 就是从库存放备份文件目录 |
3.9、在从库侧执行恢复操作
3.9.1、文件copy-back
xtrabackup
--defaults-file=/etc/my.cnf --copy-back --parallel=10 --target-dir=/root/test 如果这里的target-dir直接是从库数据库文件目录，则无需执行本步骤 |
3.9.2、文件权限配置
chown -R
mysql:mysql var/lib/mysql 如果前面执行文件传输、解压都是用mysql用户的话，则无需执行本步骤。 |
3.10、从库启动数据库实例
3.10.1、创建/var/run/mysqld目录
mkdir -p
/var/run/mysqld chown -R
mysql:mysql var/run/mysqld |
3.10.2、启动从库实例
mysqld_safe --default-file=/etc/my.cnf& 注：很多人有个误区，认为搭建从库，需要提前创建个空白实例。对于逻辑备份确实如此，但对于物理备份，则无此必要，直接使用 mysqld_safe 启动还原后的备份文件即可。 |
3.11、获取binlog和position信息
more
xtrabackup_binlog_info 恢复所需的binlog和position信息在备份时会存放target-dir下的xtrabackup_binlog_info 文件中。 |
3.12、在从库执行同步配置
change master to master_host='192.168.56.18',master_user='slave',master_password='mysql123456',master_log_file='mysql-bin.000017',master_log_pos=157; master_host为主服务器的ip； master_user为连接主服务器的用户名； master_password为连接主服务器的密码； master_log_file为要同步的日志文件file，即对应上面主服务器查看时的File字段； master_log_pos为要同步日志文件的位置，即对应上面主服务器查看时的Position字段； |
3.13、在从库侧开启同步slave进程
start slave; |
3.14、在从库侧查看slave状态
start slave; Slave_IO_Running: Yes Slave_SQL_Running: Yes 都为Yes则代表配置成功。 |
四、数据同步测试
4.1、在主库侧mydb创建一个test表
use mydb; create table test(id int); |
4.2、在从库侧查看同步情况
use mydb; show tables; |
4.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; |
4.4、在从库侧确认mydb.test记录同步情况
use mydb; select count(1) from test; |
4.5、再次查看主从库同步情况
4.5.1、主库侧
show master status\G; |
4.5.2、从库侧
show slave status\G; |
