Day05 03-MySQL主从-主主原理与搭建详解
文章目录
-
-
- 第十六章 MySQL的系统架构（主从架构）
-
- 16.1 MySQL集群架构的介绍
-
- 16.1.1 主从架构介绍
- 16.1.2 主从复制的原理
- 16.2 MySQL主从复制的实现
-
- 16.2.1 环境说明
- 16.2.2 主库配置
- 16.2.3 从库配置
- 16.2.4 主从复制测试
- 16.3 MySQL主主复制的实现
-
- 16.3.1 主主复制介绍
- 16.3.2 主库1配置
- 16.3.3 主库2配置
- 16.3.4 设置同步
-
第十六章 MySQL的系统架构（主从架构）
16.1 MySQL集群架构的介绍
我们在前面使用到MySQL数据库的时候，只是一个单机的数据库服务。在实际的生产环境中，数据量可能会非常庞大，这样单机服务的MySQL在使用的时候，性能会受到影响影响。并且单机服务的MySQL的数据安全性也会受到影响。因此在生产环境中，我们通常搭建MySQL的集群架构，来提高庞大数据量的基础上的高性能读写的需求。
在常见的集群架构中，最常见的就是主从架构(Master-Slaves)
16.1.1 主从架构介绍
MySQL的主从架构，又有一些其他的名称：主从模式、主从复制等。所谓的主从架构指的是建立多个完全一样的数据库，其中一个数据库作为主库（主要是用的数据库），其他的作为从库（次要的数据库）。主从架构分为很多种：一主一从、双主架构、一主多从、多主多从等模式。通常主库可读可写，从库只读。
MySQL最常见也是最简单的主从架构的实现就是**主从复制(MySQL Replication)**模式，这也是MySQL自带的功能，无需借助第三方的工具，就可以实现一个主从架构的集群模式。
主从架构相比较于单机服务的MySQL来说，优势有很多，最常见的优势就是：写操作连接主库，读操作连接从库，实现读写分离。
16.1.2 主从复制的原理
主从复制是通过重演binlog来实现主库数据的异步复制。即在主库上打开binlog记录每一次的数据库操作，然后从库会有一个IO线程，负责跟主库建立TCP连接，请求主库将binlog传输到从库。此时主库上会有一个Log Dump线程，负责通过这个TCP连接吧binlog日志传输给从库的IO线程。接着从库的IO线程会把读取到的binlog日志数据写入自己的中继日志文件(Relay)中。然后从库上另外一个SQL线程会读取中继日志文件中的操作，进行操作重演，达到还原数据的目的。
- 主库的数据发生了变更，将日志写入到主库的binlog中。
- 主库的LogDump线程，将binlog文件传输到从库的IO线程。
- 从库的IO线程将接收到的binlog写入到relay log中。
- 从库的SQL线程读取relay log中的日志，并操作重演，将结果同步到从库中。
16.2 MySQL主从复制的实现
16.2.1 环境说明
要实现MySQL的主从架构的搭建，需要满足以下条件：
- 所有节点的MySQL版本必须一致。
- 所有节点的时间必须同步。
- 所有节点需要启动binlog服务。
16.2.2 主库配置
我们需要编辑MySQL配置文件，这个配置文件在不同的操作系统中的位置和名字都不同，需要根据自己的操作系统来查找这个文件：
- Windows: C:\ProgramData\MySQL\MySQL Server 8.0\my.ini
- Linux: /etc/my.cnf
- macOS:
- dmg安装: /etc/my.cnf
- homebrew安装:
- Intel CPU: /usr/local/homebrew/etc/my.cnf
- AppleSilicon CPU: /opt/homebrew/etc/my.cnf
# 在[mysqld]的下方添加或修改如下属性:
# 服务节点的唯一标识，需要给集群中的每个服务分配一个单独的ID
server-id=101
# 打开binlog日志，并指定文件名
log_bin=master-bin
# binlog日志文件
log_bin-index=master-bin.index
修改完成之后，需要重启MySQL服务。
为root用户分配replication slave的权限：
# 登录到主库
mysql -uroot -p
# 为root用户分配权限
# MySQL8中，需要先添加 'root'@'%' 这个用户
# create user 'root'@'%' identified by '123456'
mysql> grant replication slave on *.* to 'root'@'%';
mysql> flush privileges;
# 查看主节点同步状态
mysql> show master status;
# +-------------------+----------+--------------+------------------+-------------------+
# | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
# +-------------------+----------+--------------+------------------+-------------------+
# | master-bin.000001 | 543 | | | |
# +-------------------+----------+--------------+------------------+-------------------+
# 1 row in set (0.00 sec)
在上述输出结果中:
File: 当前日志文件
Position: 日志文件中的索引
Binlog_Do_DB: 需要记录binlog日志的库，不设置表示全部的库
Binlog_Ignore_DB: 不需要记录binlog日志的库
16.2.3 从库配置
我们需要编辑MySQL配置文件，这个配置文件在不同的操作系统中的位置和名字都不同，需要根据自己的操作系统来查找这个文件：
- Windows: C:\ProgramData\MySQL\MySQL Server 8.0\my.ini
- Linux: /etc/my.cnf
- macOS:
- dmg安装: /etc/my.cnf
- homebrew安装:
- Intel CPU: /usr/local/homebrew/etc/my.cnf
- AppleSilicon CPU: /opt/homebrew/etc/my.cnf
# 在[mysqld]的下方添加或修改如下属性:
# 服务节点的唯一标识，需要给集群中的每个服务分配一个单独的ID
# 一定要注意，不能和其他节点重复
server-id=102
# 打开binlog日志，并指定文件名
log_bin=slave-bin
# 打开relaylog日志
relay_log=slave-relay-bin
relay_log-index=slave-relay-bin.index
skip-slave-start
修改完成之后，需要重启MySQL服务。
然后登录到其他从库，设置从主库同步状态:
# 登录从库
mysql -uroot -p
# 设置同步主节点
change master to
master_host='192.168.10.101', # 设置主库的地址
master_port=3306, # 设置主库使用的端口号
master_user='root', # 设置主库的用户名
master_password='123456', # 设置主库的密码
master_log_file='master-bin.000001', # 设置主库正在使用的binlog文件，可以在主库使用 show master status 查询
master_log_pos=543; # 设置从什么位置同步
# 开启slave
start slave;
# 查看主从同步状态
show slave status;
# 也可以使用 show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for source to send event
Master_Host: 192.168.10.101
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-bin.000001
Read_Master_Log_Pos: 916
Relay_Log_File: slave-relay-bin.000002
Relay_Log_Pos: 1133
Relay_Master_Log_File: master-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
正常的结果是如上所示的结果，但是总有意外的时候:
有些同学可能会出现 Slave_IO_Running: Connecting 的状态，甚至是NO的状态，说明从库的IO线程启动失败。原因如下:
可能是主库设置错误，检查 master_host 和 master_port 的设置是否正确
可能是主库的用户名和密码错误，检查 master_user 和 master_password 是否正确
可能是主库防火墙未关闭，检查防火墙
可能是主库不能远程登录，检查主库用户的远程登录权限
可能是 master_log_file 文件设置出问题
可能是虚拟机克隆，导致的两个节点的uuid相同
检查 /var/lib/mysql/auto.cnf 中记录的uuid，如果相同的话，随便修改一个，重启服务即可
上述几种错误情况在修改之后，都是需要重新启动slave服务的。先使用 stop slave 停止服务；再使用 start slave 开启
有些同学可能会出现 Slave_SQL_Running: No 的状态，说明从库的SQL线程启动失败，一般是因为执行主库同步过来的数据的时候失败了，例如需要创建的数据库、表已经存在导致。
解决方案：
- 删除从库中同名的库、表，从主库的日志中恢复数据。
- 如果想要保留从库中的库、表，先停止slave服务，设置 set global sql_slave_skip_counter = 1; 来设置需要跳过的错误的个数。1是可以修改的，想要跳过几个错误，就设置为多少。然后启动slave服务即可。
16.2.4 主从复制测试
我们在主库中创建数据库、创建表，可以在从库中看到有数据同步过来了。而且在从库中使用 show slave status \G 来查看从库的状态的时候，会发现记录的Pos位置已经更新。
16.3 MySQL主主复制的实现
16.3.1 主主复制介绍
MySQL的主从复制架构下，可以实现读写分离、业务分流，来降低单个数据库的压力。但是这种模式下会存在单点故障的问题，即如果主库节点宕机的情况下，对从库进行的操作并不会同步到主库中。这个数据库也就无效了。因此有的时候我们会搭建主主复制的架构，也叫做双主架构。
双主架构的实现，是在主从架构的基础之上的。将两台MySQL之间互为彼此的主库，同时又互为对方的从库。这样的实施方案下，既能做到分流，也能解决单点故障的问题。因为任何的一台节点故障，另外的一台都可以继续提供服务。
16.3.2 主库1配置
我们需要编辑MySQL配置文件，这个配置文件在不同的操作系统中的位置和名字都不同，需要根据自己的操作系统来查找这个文件：
- Windows: C:\ProgramData\MySQL\MySQL Server 8.0\my.ini
- Linux: /etc/my.cnf
- macOS:
- dmg安装: /etc/my.cnf
- homebrew安装:
- Intel CPU: /usr/local/homebrew/etc/my.cnf
- AppleSilicon CPU: /opt/homebrew/etc/my.cnf
# 在[mysqld]的下方添加或修改如下属性:
# 服务节点的唯一标识，需要给集群中的每个服务分配一个单独的ID
server-id=101
# 打开binlog日志，并指定文件名
log_bin=master-101-bin
# binlog日志文件
log_bin-index=master-101-bin.index
# 打开relaylog日志
relay_log=master-101-relay-bin
relay_log-index=master-101-relay-bin.index
skip-slave-start
# 防止两个主库中同时操作自增的字段导致字段冲突
auto_increment_increment=2 # 自增步长，一般有几个MySQL就设置为几
auto_increment_offset=1 # 自增起始值
修改完成之后，需要重启MySQL服务。
为root用户分配replication slave的权限：
# 登录到主库
mysql -uroot -p
# 为root用户分配权限
# MySQL8中，需要先添加 'root'@'%' 这个用户
# create user 'root'@'%' identified by '123456'
mysql> grant replication slave on *.* to 'root'@'%';
mysql> flush privileges;
16.3.3 主库2配置
我们需要编辑MySQL配置文件，这个配置文件在不同的操作系统中的位置和名字都不同，需要根据自己的操作系统来查找这个文件：
- Windows: C:\ProgramData\MySQL\MySQL Server 8.0\my.ini
- Linux: /etc/my.cnf
- macOS:
- dmg安装: /etc/my.cnf
- homebrew安装:
- Intel CPU: /usr/local/homebrew/etc/my.cnf
- AppleSilicon CPU: /opt/homebrew/etc/my.cnf
# 在[mysqld]的下方添加或修改如下属性:
# 服务节点的唯一标识，需要给集群中的每个服务分配一个单独的ID
server-id=102
# 打开binlog日志，并指定文件名
log_bin=master-102-bin
# binlog日志文件
log_bin-index=master-102-bin.index
# 打开relaylog日志
relay_log=master-102-relay-bin
relay_log-index=master-102-relay-bin.index
skip-slave-start
# 防止两个主库中同时操作自增的字段导致字段冲突
auto_increment_increment=2 # 自增步长，一般有几个MySQL就设置为几
auto_increment_offset=2 # 自增起始值
修改完成之后，需要重启MySQL服务。
为root用户分配replication slave的权限：
# 登录到主库
mysql -uroot -p
# 为root用户分配权限
# MySQL8中，需要先添加 'root'@'%' 这个用户
# create user 'root'@'%' identified by '123456'
mysql> grant replication slave on *.* to 'root'@'%';
mysql> flush privileges;
16.3.4 设置同步
-
查看master1的binlog
+-----------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +-----------------------+----------+--------------+------------------+-------------------+ | master-101-bin.000001 | 156 | | | | +-----------------------+----------+--------------+------------------+-------------------+ -
设置master2同步master1
# 登录从库 mysql -uroot -p # 设置同步主节点 change master to master_host='192.168.10.101', master_port=3306, master_user='root', master_password='123456', master_log_file='master-101-bin.000001', master_log_pos=156; -
查看master2的binlog
+-----------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +-----------------------+----------+--------------+------------------+-------------------+ | master-102-bin.000001 | 553 | | | | +-----------------------+----------+--------------+------------------+-------------------+ -
设置master1同步master2
# 登录从库 mysql -uroot -p # 设置同步主节点 change master to master_host='192.168.10.102', master_port=3306, master_user='root', master_password='123456', master_log_file='master-102-bin.000001', master_log_pos=553; -
开启同步
# 分别启动两个数据库的slave start slave # 如果出现错误：Slave failed to initialize relay log info structure from the repository # 说明之前存在主从模式下的relay log，使用reset slave命令清除即可
参考链接:https://blog.csdn.net/u010839779/article/details/128012245?spm=1001.2014.3001.5501