首页 > 数据库 > Mysql > Linux MySQL主从复制

Linux之MySQL主从复制方式

2024-11-16 09:08:49 作者：何老生

本文介绍了MySQL的主从复制原理和配置步骤,包括主从库的配置、同步操作和异常处理,主从复制通过二进制日志实现数据同步,适用于读写分离和备份等场景,配置过程中需要注意server_id的唯一性,确保主从同步的顺利进行

概述

MySQL的主从复制（Master-Slave Replication）是一种数据复制解决方案，将主数据库的DDL（数据定义语言）和DML（数据操纵语言）操作通过二进制日志传到从库服务器中，然后在从库上对这些日志重新执行（也叫重做），从而是的从库和主库的数据保存同步。

MySQL支持将数据从一个MySQL服务器（主服务器）复制到一个或多个其他MySQL服务器（从服务器），从库同时也可以作为其他从服务器的主库，实现链状复制。

MySQL主从复制的优点主要包含以下三个方面：

主库出现问题，可以快速切换到从库提供服务；实现读写分离，降低主库的访问压力；可以在从库中执行备份，以避免备份期间影响主库服务；

需要注意的是，MySQL的主从复制是异步的，这意味着从服务器的数据可能会与主服务器的数据存在一定的延迟。因此，在使用主从复制时，需要根据具体的业务场景和需求来选择合适的配置和策略。

工作原理

从上图来看，主从复制分成三步：

Master主库在事务提交时，会把数据变更记录在二进制日志文件Binlog中；
从库读取主库的二进制日志文件Binlog，写入到从库的中继日志Relay Log；
Slave重做中继日志中的事件，将改变数据更新同步到从库中；

说白了就是Master主库上执行的增删改的SQL语句同步到对应的Slave从库上，然后再在Slave从库中同样再次执行一遍SQL语句以作备份。

综合案例

前期准备

准备两台虚拟机，需要提前安装好MySQL数据库（必须要开启二进制日志）。

如下所示：

主从库	IP地址
主库	192.168.111.135
从库	192.168.111.137

注意：以上只是示例说明，具体以自己的虚拟机情况为主。

例外如果克隆的两台虚拟机IP地址一致，可根据以下操作修改实现动态ip（基于mac地址发配IP）

切换目录到：/etc/netplan 并且编辑00-installer-config.yaml文件

如下图指定位置加入：dhcp-identifier: mac(严格缩进格式要求)

重启网络刷新修改：netplan apply

主库配置

修改主库服务器的MySQL核心配置文件/etc/mysql/mysql.conf.d/mysqld.cnf，并添加如下配置信息（开启二进制日志）：

[mysqld]
...
# 开启二进制日志（必须）
log-bin = mysql-bin
# MySQL服务ID，保证整个集群环境中唯一，默认为1（必须）
server-id = 1
# 二进制日志格式，默认ROW（可选）
binlog_format = ROW
# 忽略的数据，不需要同步的数据库
# binlog-ignore-db = db1
# binlog-ignore-db = db2
# 指定同步的数据库
# binlog-do-db = db3

注意：这里binlog-ignore-db和binlog-do-db配置项没有指定，默认同步所有数据库信息。
从 MySQL 5.7 开始，binlog-ignore-db 的优先级高于 binlog-do-db。这意味着即使某个数据库被 binlog-do-db 指定，如果它同时出现在 binlog-ignore-db 的列表中，那么它的更改将不会被记录到二进制日志中

重启MySQL服务器。

systemctl restart mysql

（追求安全，否则可跳过）登录MySQL数据库，创建远程连接的账号，并授予主从复制权限。

# 创建xx用户，并设置密码，该用户可在任意主机连接该MySQL服务
create usxx'@'%' identified with mysql_native_password by 'xx1234';
# 为'xx'@'%'用户分配主从复制权限
grant replication slave on *.* to 'zking'@'%';

通过指令，查看二进制日志坐标

show master status;

从库配置

1）修改从库服务器的MySQL核心配置文件/etc/mysql/mysql.conf.d/mysqld.cnf，并添加如下配置信息：

[mysqld]
...
# 开启二进制日志（必须）
log-bin = mysql-bin
# MySQL服务ID，保证整个集群环境中唯一，默认为1（必须）
server-id = 2
# 二进制日志格式，默认ROW（可选）
binlog_format = ROW
# 是否只读，1代表只读，0代表读写
read-only = 1

2）重启MySQL服务器。

systemctl restart mysql

3）登录MySQL数据库，设置主库配置。

MySQL8.0.23之前的版本，执行如下SQL语句：

change master to master_host='xxx.xxx.xxx.xxx',master_user='xxx',master_password='xxx',master_log_file='xxx',master_log_pos=xxx;
change master to master_host='192.168.111.135',master_user='root',master_password='123',master_log_file='mysql_bin.000008',master_log_pos=2756;

MySQL8.0.23之后的版本，执行如下SQL语句：

change replication source to source_host='xxx.xxx.xxx.xxx',source_user='xxx',source_password='xxx',source_log_file='xxx',source_log_pos=xxx;

参数说明：

参数名	含义	8.0.23之前
source_host	主库IP地址	master_host
source_user	连接主库的用户名	master_user
source_password	连接主库的密码	master_password
source_log_file	binlog日志文件名	master_log_file
source_log_pos	binlong日志文件位置	master_log_pos

4）开启同步操作

# 8.0.22之后
start replica; 
# 8.0.22之前
start slave;

5）查看主从同步状态

# 8.0.22之后
show replica status; 
# 8.0.22之前
show slave status;

格式化显示：show slave status\G;

上述图中显示Slave_IO_Running: No，很明显主从复制开启失败。经过问题分析之后，发现是虚拟机是克隆的，导致主库和从库的MySQL的server id都是一样的。

解决方案：修改任意主库和从库的server id即可解决问题。

修改/var/lib/mysql/auto.cnf文件。将server-uuid属性修改为唯一值即可。

[auto]
server-uuid = 任意uuid

方案二：

停止mysql服务
删除auto.cnf
启动mysql服务

修改完毕保存并退出，最后重启MySQL服务后，并再次登录MySQL查看主从复制是否成功。

数据测试

1）登录主库MySQL，并执行以下SQL语句：

# 切换数据库
use db1;
# 创建数据表t_student
create table t_student(sid int primary key auto_increment,sname varchar(20) not null,sage int default 0,ssex varchar(2) default '1');
# 批量添加数据
insert into t_student(sname,sage,ssex) values('张三',26,'男'),('王五',22,'女'),('小七',23,'女');

2）登录从库MySQL，查看主从复制结果：

# 切换数据库
use db1;
# 查看是否存在t_student表
show tables;
# 查看t_student表中是否存在数据
select * from t_student;

存在数据即MySQL主从复制同步成功（主库操作，从库也会有）。

异常处理

# 授权&创建用户
mysql> grant select,insert,file on test.* to test@'%' identified by '123';
ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES
mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select host,user from user;(test并没有权限)
+-----------+---------------+
| host      | user          |
+-----------+---------------+
| %         | root          |
| %         | test          |
| localhost | mysql.session |
| localhost | mysql.sys     |
+-----------+---------------+
4 rows in set (0.00 sec)
mysql> show grants for test;
+----------------------------------+
| Grants for test@% |
+----------------------------------+
| GRANT USAGE ON *.* TO 'test'@'%' |【为默认权限，所有用户都有】
+----------------------------------+
1 row in set (0.00 sec)

mysql> grant select,insert on test.* to test@'%' identified by '123';

Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> show grants for test;
+------------------------------------------------+
| Grants for test@% |
+------------------------------------------------+
| GRANT USAGE ON *.* TO 'test'@'%' |
| GRANT SELECT, INSERT ON `test`.* TO 'test'@'%' |
+------------------------------------------------+
2 rows in set (0.00 sec)

在创建用户时对 test 库授予 SELECT、INSERT、FILE 权限，因 FILE 权限不能授予某个数据库而导致语句执行失败。

但最终结果是：test@'%' 创建成功，授权部分失败。

从上面的测试可知，使用 GRANT 创建用户其实是分为两个步骤：创建用户和授权。

权限有问题并不影响用户的创建，上述语句会导致主库在 binlog 写 INCIDENT_EVENT，从而导致主从复制报错

故障解决

 mysql> stop slave;
 mysql> set global sql_slave_skip_counter=1; #指定跳过事务个数
 mysql> start slave;

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。