とあるMySQLの主从架构

JavaDevelopmentDM

已于 2023-02-01 11:13:46 修改

阅读量428

点赞数 2

分类专栏： MySQL 文章标签： mysql 分布式数据库

于 2021-01-04 16:46:31 首次发布

本文链接：https://blog.csdn.net/JAVA_php_Jack/article/details/112184427

版权

MySQL 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

前言

为什么需要MySQL主从架构呢？

在实际生产中，随着用户量的提升，需要处理的数据往往会是极为庞大的，同时数据的安全性要求也会更高，想一想，你吃着火锅唱着歌，突然，MySQL数据库爆了，你的云盘账号丢失了，几个T的种子全没了qaq~

所以，在生产环境中，MySQL必须搭建一套主从复制的架构。作为master的MySQL一个劲的增删改你的数据，然后作为slave的MySQL一个劲的复制master里面的数据，如果说slave顺便完成你读的操作，那是不是……（坏笑.jpg）

没错，这样子什么读写分离什么高可用不就来了吗，数据库还怕撑爆吗😏

然后我们就可以快乐地再多保存一些数据了，然后……一个表的数据上万……

（相信屏幕前的你会说“分库分表”）

当然，解决一个问题的同时也将带来更多的问题，所以我们还是得根据具体的情况去具体地分析的……那么，我们现在一步一步的入坑吧

本文章参考MySQL官方文档，如遇到其他问题，可在评论区评论或查看官方文档解决：

5.7：https://dev.mysql.com/doc/refman/5.7/en/replication.html

8.0：https://dev.mysql.com/doc/refman/8.0/en/replication.html

前期准备

至少是要有两台主机的，笔者这里有一台119.3.X.X（主），还有一台47.97.X.X（从）这两台centOS7的机器（看看翻车的概率大不大，顺便比较两家网速……）
下载的MySQL5.7（也可以用8.0的版本，亲测有效，但是个人喜欢5.7）

MySQL安装参考本人另一篇博客：https://blog.csdn.net/JAVA_php_Jack/article/details/104016982

为了便于使用，两个mysql服务需要打开远程登录权限，开启方式需要在本机登录 mysql，执行以下语句。

#开启远程登录
use mysql;
update user set host='%' where user='root';
flush privileges;

在这里插入图片描述

当然，最好还是创建一个拥有全部权限的用户来负责主从同步，我这里各自创建一个master用户grant all on *.* to master@'47.97.xxx.xxx' identified by '密码';和salve用户grant all on *.* to salve@'%' identified by '密码';用来后续使用（创建完从数据库的‘salve’@‘%’用户后如果需要使用‘salve’@‘localhost’用户，还需要再创建：grant all on *.* to salve@'localhost' identified by '密码';）：

在这里插入图片描述
关于如何新建用户配置权限的操作我之前的博客已有说明：https://blog.csdn.net/JAVA_php_Jack/article/details/104017941

搭建主从集群

理论基础

//（写这部分是因为笔者还在下载MySQL等着截屏插图就没事瞎编水篇幅的）

主从架构有什么用呢？我们刚刚上面也说了一个是做备份，一个读写分离，还有就是高可用，具体如下：

数据安全

给主服务增加一个数据备份（就不怕数据丢失了，安全）。基于这个目的，搭建主从架构或者是基于主从架构搭建互主的架构（也就是两个MySQL互相都是对方的master又互相都是对方的slave）。
读写分离

首先说明一下，在实际生产中我们是不允许从服务器去修改数据的（增删改，可以先思考一下为什么）。在大多的Java业务系统中，读多写少，读请求是远远多于写请求的。如果说让主服务器只做写的操作，从服务器只做读的操作，这就可以大大地去缓解数据库的访问压力了。当然，MySQL的主从架构只是实现读写分离的一个基础。实现读写分离还是需要一些中间件来支持，比如ShardingSphere。
故障转移——高可用

主服务如果GG了，反正从服务也有数据，只要数据没有丢失，让从服务暂时上来做老大不也是可以的啦。对于高可用架构，主从数据的同步也只是实现故障转移的一个前提条件，要实现MySQL主从切换，还需要依靠一些其他的中间件来实现。比如MMM、MHA、MGR。

同步原理

搞事情一定得知道原理，知其然知其所以然嘛。先上图：
在这里插入图片描述
如上图，MySQL服务的主从架构一般都是通过binlog日志文件来进行的，在主服务上打开binlog记录每一步的数据库操作，然后从服务上会有一个IO线程，负责跟主服务建立一个TCP连接，请求主服务将binlog传输过来。这时主库上会有一个IOdump线程，负责通过这个TCP连接把binlog日志传输给从库的IO线程。接着从服务上另外一个SQL线程会读取relay日志里的内容，进行操作重演，达到还原数据的目的。我们通常对MySQL做的读写分离配置就必须基于主从架构来搭建。

我们的binlog也不光光是可以用于做主从架构的，而且也可以用来缓存数据同步等场景。例如Canal，可以模拟一个salve节点，向MySQL发起binlog同步，然后将数据落地到redis、kafka等其他组件，实现数据实时流转。

注意，搭建主从集群时，我们需要注意这两个要求：

双方的MySQL必须版本一致，至少需要主服务的版本低于从服务
两节点间的时间需要同步

实操

配置master主服务器

配置主节点的mysql配置文件vim /etc/my.cnf，打开binlog日志以及指定server-id：
```
[mysqld]
#主库和从库需要不一致
server-id=66
#开启binlog
log_bin=master-bin
log_bin-index=master-bin.index
```
说明：
1. server-id：服务节点的唯一标识，需要给集群中的每个服务都分配一个单独的ID
2. log_bin：打开Binlog日志记录，并指定文件名
3. log_bin-index：Binglog日志文件
重启MySQL：service mysqld restart或systemctl restart mysqld
然后我们还需要给主服务器的master用户分配一个replication slave的权限：
```
grant replication slave on *.* to master@'47.97.XX.XX';
--刷新
flush privileges;
--查看主节点同步状态：
show master status;
```
在实际生产环境中，通常不会直接使用root用户，而会创建一个拥有全部权限的用户来负责主从同步。

binlog默认用一组5个轮询文件循环记录每一步的数据库操作，这个表的File字段记录的是当前日志的binlog文件，Position是当前记录到文件的哪个位置（索引）。在后面配置主从服务的时候就需要通过File和Position通知从哪个地方开始记录binlog。

当然，这个binlog文件的位置就在配置文件的datadir（MySQL数据存放的目录）那里找

配置slave从服务

配置从节点的mysql配置文件vim /etc/my.cnf，打开中继日志、binlog以及指定server-id：

[mysqld]
#主库和从库需要不一致
server-id=69
#打开MySQL中继日志
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
#设置只读权限
#read_only=1;
#开启binlog
log_bin=slave-bin
#使得更新的数据写进二进制日志中
log-slave-updates=1

从节点配置文件.png
说明：relay-log：打开从服务的relay-log日志

这里还有一个设置只读权限，但是我暂时没有打开，大家可以先思考一下。

重启MySQL：service mysqld restart或systemctl restart mysqld
启动MySQL服务，设置他的主节点同步状态：
```
-- 登录从服务
mysql -u salve -p

-- 设置同步主节点：（这个具体参数要看情况配置，先别着急，看完这第三步再操作）
CHANGE MASTER TO
MASTER_HOST='119.3.XX.XX',
MASTER_PORT=3306,
MASTER_USER='master',
MASTER_PASSWORD='密码',
MASTER_LOG_FILE='master-bin.000001',
MASTER_LOG_POS=508;

-- 开启slave
start slave;

-- 查看主从同步状态
show slave status \G;
```
说明：
1. CHANGE MASTER TO更改副本用于连接到复制源服务器，读取源的二进制日志以及读取副本的中继日志的参数。它还会更新复制元数据存储库的内容（请参见第16.2.4节“中继日志和复制元数据存储库”）。CHANGE MASTER TO需要 SUPER特权。
2. MASTER_HOST、MASTER_PORT：主服务的ip及端口号
3. MASTER_USER、MASTER_PASSWORD：连接的主服务的用户及密码
4. MASTER_LOG_FILE、MASTER_LOG_POS：必须和主服务中查询的主节点同步状态的File和Position保持一致（从当前的binlog开始备份），并且后续如果要检查主从架构是否成功，也可以通过检查主服务与从服务之间的File和Position这两个属性是否一致来确定。
  
  如图，当我们看到第一个红色方框的两个属性，与主节点保持一致，第二个方框两个属性都是yes，就表示这个主从同步搭建是成功的。

从这个指令的结果能够看到，有很多Replicate_开头的属性，这些属性指定了两个服务之间要同步哪些数据库、哪些表的配置。只是在我们这个示例中全都没有进行配置，就标识是全库进行同步。后面我们会补充如何配置需要同步的库和表。

主从集群测试

在这里插入图片描述

如图。我们在主服务上建了新的数据库，从服务也会跟着创建数据库。当然，我在主服务建表，增删改查等等的操作也会同步到从服务上，就不上图了，大家自己试试。

从服务有事务回滚导致主从同步失败

如果在slave从服务上查看slave状态，发现Slave_SQL_Running=NO，就表示主从同步失败了。这有可能是因为在从数据库上进行了写操作，与同步过来的SQL操作冲突了，也有可能是slave从服务重启后有事务回滚了。

如果是因为slave从服务事务回滚的原因，可以按照以下方式重启主从同步：

官方文献参考：（若链接失效，自行在MySQL官网对应MySQL版本文档搜索SQL_SLAVE_SKIP_COUNTER）https://dev.mysql.com/doc/refman/5.7/en/replication-problems.html
```
stop slave;
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
start slave;
```
如果在源上成功执行的语句拒绝在副本上运行，请执行以下过程，如果通过删除副本的数据库并从源复制新快照来进行完全数据库重新同步是不可行的：

如果您确定副本可以跳过源中的下一条语句，请发出以下语句：
```
mysql> SET GLOBAL sql_slave_skip_counter = N;
mysql> START SLAVE;
```
N：如果源中的下一个语句不使用AUTO_INCREMENT或者LAST_INSERT_ID()，则值应为1 。否则，该值应为2。之所以对使用AUTO_INCREMENT或LAST_INSERT_ID()的语句使用2值，是因为它们在源的二进制日志中包含两个事件。

另请参见 SET GLOBAL sql_slave_skip_counter语句。
另一种解决方式就是重新记录主节点的binlog文件消息
```
stop slave ;
change master to .....
start slave ;
```
但是这种方式要注意binlog的文件和位置，如果修改后和之前的同步接不上，那就会丢失部分数据。所以不太常用。

集群搭建扩展

全库同步与部分同步

我们现在配置的主从同步是针对全库配置的，而实际环境中，一般并不需要针对全库做备份，而只需要对一些特别重要的库或者表来进行同步。那如何针对库和表做同步配置呢？

master端：在配置文件my.cnf中，可以通过以下属性指定需要针对哪些库或者哪些表记录binlog：

#需要同步的二进制数据库名
binlog-do-db = masterdemo
#只保留7天的二进制日志，以防磁盘被日志占满(可选)
expire-logs-days = 7
#不备份的数据库
binlog-ignore-db = information_schema
binlog-ignore-db = performation_schema
binlog-ignore-db = sys

slave端：在my.cnf中，需要配置备份库与主服务的库的对应关系。

#如果salve库名称与master库名相同，使用本配置
replicate-do-db = masterdemo
#如果master库名[mastdemo]与salve库名[mastdemo01]不同，使用以下配置[需要做映射]
replicate-rewrite-db = masterdemo -> masterdemo01
#如果不是要全部同步[默认全部同步]，则指定需要同步的表
replicate-wild-do-table = masterdemo01.t_dict
replicate-wild-do-table = masterdemo01.t_num

配置完成了之后，在show master status指令中，就可以看到Binlog_Do_DB（备份的数据库）和 Binlog_Ignore_DB（不备份的数据库）两个参数的作用了。

读写分离

我们要注意，目前我们的这个MySQL主从集群是单向的，也就是只能从主服务同步到从服务，而从服务的数据表是无法同步到主服务的。

所以，在这种架构下，为了保证数据一致，通常会需要保证数据只在主服务上写，而从服务只进行数据读取。这个功能，就是大名鼎鼎的读写分离。但是这里要注意下，mysql主从本身是无法提供读写分离的服务的，需要由业务自己来实现。我们可以使用ShardingSphere来实现它。

到这里可以看到，在MySQL主从架构中，是需要严格限制从服务的数据写入的，一旦从服务有数据写入，就会造成数据不一致。并且从服务在执行事务期间还很容易造成数据同步失败。

如果需要限制用户写数据，我们可以在从服务中将read_only参数的值设为1( set global read_only=1; )。这样就可以限制用户写入数据。但是这个属性有两个需要注意的地方：

read_only=1设置的只读模式，不会影响slave同步复制的功能。所以在MySQL slave库中设定了read_only=1后，通过 “show slave status\G” 命令查看salve状态，可以看到salve仍然会读取master上的日志，并且在slave库中应用日志，保证主从数据库同步一致；
read_only=1设置的只读模式，限定的是普通用户进行数据修改的操作，但不会限定具有super权限的用户的数据修改操作。在MySQL中设置read_only=1后，普通的应用用户进行insert、update、delete等会产生数据变化的DML操作时，都会报出数据库处于只读模式不能发生数据变化的错误，但具有super权限的用户，例如在本地或远程通过root用户登录到数据库，还是可以进行数据变化的DML操作；如果需要限定super权限的用户写数据，可以设置super_read_only=0。另外，如果要想连super权限用户的写操作也禁止，就使用"flush tables with read lock;"，这样设置也会阻止主从同步复制！

这样我们也顺便解决前面的问题了，总的来说，在实际的生产环境中我们是不能使用从服务进行写操作的，可以设置read_only=1，同时，业务登录的MySQL一定不能使用具有super权限的用户，而应该使用具有对应业务权限的普通用户。

在这里插入图片描述

GTID同步集群

上面我们搭建的集群方式，是基于Binlog日志记录点的方式来搭建的，这也是最为传统的MySQL集群搭建方式。而在这个实验中，可以看到有一个 Executed_Grid_Set列，暂时还没有用上。实际上，这就是另外一种搭建主从同步的方式，即GTID搭建方式。这种模式是从MySQL5.6版本引入的。

GTID的本质也是基于Binlog来实现主从同步，只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID，全局唯一并且趋势递增，他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID。

在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。

他的搭建方式跟我们上面的主从架构整体搭建方式差不多。只是需要在my.cnf中修改一些配置。

此次直接引用MySQL参考文档（个人翻译的可能不是很好，建议大家参考原文档进行操作）https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-howto.html

步骤1：同步服务器。 如果服务器已经搭建了主从复制，都需要先把服务器设置为只读服务器，否则从第三步开始操作。

mysql> SET @@GLOBAL.read_only = ON;

当然，我们之前的slave已经是只读服务器了，所以不用设置。但是需要将slave先STOP SLAVE;。

等待所有正在进行的事务提交或回滚。然后，允许副本追赶源。在继续之前，确保副本已处理所有更新，这一点非常重要。

如果您将二进制日志用于复制以外的其他用途，例如进行时间点备份和还原，请等到你不需要包含没有GTID事务的旧的二进制日志。理想情况下，请等待服务器清除所有二进制日志，然后等待任何现有备份到期。

重点：

重要的是要理解，包含事务但没有GTID的日志不能在启用了GTID的服务器上使用。在继续之前，必须确保没有GTID的事务在拓扑中的任何地方都不存在。

步骤2：停止两台服务器。 如下所示，使用mysqladmin停止每个服务器，这里*username*是具有足够特权关闭服务器的MySQL用户的用户名：

shell> mysqladmin -uusername -p shutdown

然后在提示时提供该用户的密码。

步骤3：启动两个启用了GTID的服务器。 要启用基于GTID的复制，必须通过将gtid_mode变量设置为ON来启用GTID模式，并在enforce_gtid_consistency 启用变量的情况下启动每个服务器，以确保仅记录对基于GTID的复制安全的语句。例如：（在/etc/my.cnf添加下面的语句）

gtid_mode=ON
enforce-gtid-consistency=ON

然后重启systemctl restart mysqld。

此外，--skip-slave-start在配置副本设置之前，应使用选项启动副本。有关GTID相关选项和变量的更多信息，请参见第16.1.6.5节“全局事务ID系统变量”。

当使用mysql.gtid_executed表时，可以不用为了使用GTID而启动二进制日志。复制源服务器必须始终启用二进制日志记录才能进行复制。但是，副本服务器可以使用GTID，但不使用二进制日志记录。如果需要禁用副本的二进制日志记录，可以通过指定副本的 --skip-log-bin 和--log-slave-updates=OFF选项来实现。

步骤4：将副本配置为使用基于GTID的自动定位。 告诉副本使用基于GTID的事务的源作为复制数据源，并使用基于GTID的自动定位而不是基于文件的定位。CHANGE MASTER TO在副本上发出一条语句，包括该MASTER_AUTO_POSITION语句中的选项，以告知副本源的事务由GTID标识。

您可能还需要为源的主机名和端口号以及复制用户帐户的用户名和密码提供适当的值，副本可以使用该用户名和密码来连接源。如果已经在步骤1之前设置了这些选项，并且无需进行进一步更改，则可以安全地从此处显示的语句中省略相应的选项。

mysql> CHANGE MASTER TO
     >     MASTER_HOST = host,
     >     MASTER_PORT = port,
     >     MASTER_USER = user,
     >     MASTER_PASSWORD = password,
     >     MASTER_AUTO_POSITION = 1;

如果是从文章开头一步步操作到这里的，直接CHANGE MASTER TO MASTER_AUTO_POSITION = 1;即可。

无论是MASTER_LOG_FILE选项还是MASTER_LOG_POS选项都可能与MASTER_AUTO_POSITION=1操作冲突导致CHANGE MASTER TO语句失败与错误。

步骤5：进行新备份。 启用GTID以后，在启用GTID之前进行的现有备份将无法再在这些服务器上使用。此时，请进行新的备份，以免没有可用的备份。

例如，您可以FLUSH LOGS在进行备份的服务器上执行。然后，要么明确地进行备份，要么等待您可能已设置的任何定期备份例程的下一个迭代。

步骤6：启动副本并禁用只读模式。 像这样启动副本：

mysql> START SLAVE;

仅当在步骤1中将服务器配置为只读时，才需要执行以下步骤。要使服务器再次开始接受更新，请发出以下语句：

mysql> SET @@GLOBAL.read_only = OFF;

验证成功：主服务器进行数据操作后，登录主服务器master，通过命令show master status;可以看到当前的事务gtid：
在这里插入图片描述

集群扩容

我们现在已经搭建成功了一主一从的MySQL集群架构，那要扩展到一主多从的集群架构，其实就比较简单了，只需要增加一个binlog复制就行了。

但是如果我们的集群是已经运行过一段时间，这时候如果要扩展新的从节点就有一个问题，之前的数据没办法从binlog来恢复了。这时候在扩展新的slave节点时，就需要增加一个数据复制的操作。

MySQL的数据备份恢复操作相对比较简单，可以通过SQL语句直接来完成。具体操作可以使用mysql的bin目录下的mysqldump工具。

mysqldump -u root -p --all-databases > backup.sql
#输入密码

这个语句是将所有的数据库的数据保存到一个backup.sql的文件，具体可以看官方文档：https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html

把这个backup.sql分发到新的MySQL服务器上，并执行下面的指令将数据全部导入到新的 MySQL服务中。

mysql -u root -p < backup.sql
#输入密码

半同步复制

什么是半同步复制

到现在为止，我们已经可以搭建MySQL的主从集群，互主集群，但是我们这个集群有一个隐患，就是有可能会丢数据。这是为什么呢？这要从MySQL主从数据复制分析起。

MySQL主从集群默认采用的是一种异步复制的机制，主服务在执行用户提交的事务后，写入binlod日志，然后就给客户端返回一个成功的响应了，而binlog会由一个dump线程异步发送给从服务。

由于发送binlog过程是异步的，主服务在向客户端反馈结果时是不会知道binlog是否同步成功的。这时候如果主服务宕机了，而从服务还没有备份到新执行的binlog，那就有可能会丢数据。如图所示：
在这里插入图片描述

那怎么解决这个问题呢，这就要靠MySQL的半同步复制机制来保证数据安全。

先看图：
在这里插入图片描述

有图可以看出，半同步复制机制是一种介于异步复制和全同步复制之间的机制。主库在执行完客户端提交的事务后，并不是立即返回客户端响应，而是等待一个从库接收写到relay log中，才返回客户端。

一般来说，MySQL在等待确认时，默认会等10秒，如果超时还没有接收到ack，就降级为异步复制并进行数据回滚操作。

这种半同步复制相比异步复制，能够有效的提高数据的安全性。但是这种安全性也不是绝对的，他只保证事务提交后的binlog至少传输到了一个从库，并且并不保证从库应用这个事务的binlog是成功的。另一方面，半同步复制机制也会造成一定程度的延迟，这个延迟时间最少是一个TCP/IP请求往返的时间。整个服务的性能是会有所下降的。而当从服务出现问题时，主服务需要等待的时间就会更长，要等到从服务的服务恢复或者请求超时才能给用户响应。

搭建半同步复制集群

半同步复制需要基于特定的扩展模块来实现。而mysql从5.5版本开始，往上的版本都默认自带了这个模块。这个模块包含在mysql安装目录下的lib/plugin目录下的semisync_master.so和semisync_slave.so两个文件中。需要在主服务上安装semisync_master模块，在从服务上安装semisync_slave模块。

登陆主服务，安装semisync_master模块：
```
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.01 sec)
mysql> show global variables like 'rpl_semi%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | OFF |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set, 1 warning (0.02 sec)
mysql> set global rpl_semi_sync_master_enabled=ON;
Query OK, 0 rows affected (0.00 sec)
```
这三行指令中，第一行是通过扩展库来安装半同步复制模块，需要指定扩展库的文件名。

第二行查看系统全局参数，rpl_semi_sync_master_timeout就是半同步复制时等待应答的最长等待时间，默认是10秒，可以根据情况自行调整。

第三行则是打开半同步复制的开关。

在第二行查看系统参数时，最后的一个参数rpl_semi_sync_master_wait_point其实表示一种半同步复制的方式。

半同步复制有两种方式，一种是我们现在看到的这种默认的AFTER_SYNC方式。这种方式下，主库把日志写入binlog，并且复制给从库，然后开始等待从库的响应。从库返回成功后，主库再提交事务，接着给客户端返回一个成功响应。

而另一种方式是叫做AFTER_COMMIT方式。他不是默认的。这种方式，在主库写入binlog后，等待binlog复制到从库，主库就提交自己的本地事务，再等待从库返回给自己一个成功响应，然后主库再给客户端返回响应。

登陆从服务，安装smeisync_slave模块：

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.01 sec)
mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
2 rows in set, 1 warning (0.01 sec)
mysql> set global rpl_semi_sync_slave_enabled = on;
Query OK, 0 rows affected (0.00 sec)
mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | ON |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
2 rows in set, 1 warning (0.00 sec)
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

slave端的安装过程基本差不多，不过要注意下安装完slave端的半同步插件后，需要重启下slave服务。

主从架构的数据延迟问题

在我们搭建的这个主从集群中，有一个比较隐藏的问题，就是这样的主从复制之间会有延迟。这在做了读写分离后，会更容易体现出来。即数据往主服务写，而读数据在从服务读。这时候这个主从复制延迟就有可能造成刚插入了数据但是查不到。当然，这在我们目前的这个集群中是很难出现的，但是在大型集群中会很容易出现。

出现这个问题的根本在于：面向业务的主服务数据都是多线程并发写入的，而从服务是单个线程慢慢拉取binlog，这中间就会有个效率差。所以解决这个问题的关键是要让从服务也用多线程并行复制binlog数据。

MySQL自5.7版本后就已经支持并行复制了。可以在从服务上设置slave_parallel_workers为一个大于0的数，然后把slave_parallel_type参数设置为LOGICAL_CLOCK，这就可以了。

mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables like 'slave_parallel%';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| slave_parallel_type    | DATABASE |
| slave_parallel_workers | 0        |
+------------------------+----------+
2 rows in set (0.00 sec)

mysql> set global slave_parallel_workers = 2;
Query OK, 0 rows affected (0.00 sec)

mysql> set global slave_parallel_type = LOGICAL_CLOCK;
Query OK, 0 rows affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

在这里插入图片描述

MySQL的高可用方案

我们之前的MySQL服务集群，都是使用MySQL自身的功能来搭建的集群。但是这样的集群，不具备高可用的功能。即如果是MySQL主服务挂了，从服务是没办法自动切换成主服务的。而如果要实现MySQL的高可用，需要借助一些第三方工具来实现。

常见的MySQL集群方案有三种: MMM、MHA、MGR。这三种高可用框架都有一些共同点：

对主从复制集群中的Master节点进行监控
自动的对Master进行迁移，通过VIP（虚拟IP）
重新配置集群中的其它slave对新的Master进行同步

MMM

MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一套由Perl语言实现的脚本程序，可以对mysql集群进行监控和故障迁移。他需要两个Master，同一时间只有一个Master对外提供服务，可以说是主备模式。

他是通过一个VIP(虚拟IP)的机制来保证集群的高可用。整个集群中，在主节点上会通过一个VIP地址来提供数据读写服务，而当出现故障时，VIP就会从原来的主节点漂移到其他节点，由其他节点提供服务。

在这里插入图片描述

优点：

提供了读写VIP的配置，使读写请求都可以达到高可用
工具包相对比较完善，不需要额外的开发脚本
完成故障转移之后可以对MySQL集群进行高可用监控

缺点：

故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率
目前MMM社区已经缺少维护，不支持基于GTID的复制

适用场景：

读写都需要高可用的
基于日志点的复制方式

MHA

Master High Availability Manager and Tools for MySQL。是由日本人开发的一个基于Perl脚本写的工具。这个工具专门用于监控主库的状态。当发现master节点故障时，会提升其中拥有新数据的slave节点成为新的master节点，在此期间，MHA会通过其他从节点获取额外的信息来避免数据一致性方面的问题。MHA还提供了mater节点的在线切换功能，即按需切换master-slave节点。MHA能够在30秒内实现故障切换，并能在故障切换过程中，最大程度的保证数据一致性。在淘宝内部，也有一个相似的TMHA产品。

MHA是需要单独部署的，分为Manager节点和Node节点，两种节点。其中Manager节点一般是单独部署的一台机器。而Node节点一般是部署在每台MySQL 机器上的。Node节点得通过解析各个MySQL的日志来进行一些操作。

Manager节点会通过探测集群里的Node节点去判断各个Node所在机器上的MySQL运行是否正常，如果发现某个Master故障了，就直接把他的一个Slave提升为Master，然后让其他Slave都挂到新的Master上去，完全透明。

在这里插入图片描述

优点：

MHA除了支持日志点的复制还支持GTID的方式
同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。

缺点：

MHA需要自行开发VIP转移脚本。
MHA只监控Master的状态，未监控Slave的状态

MGR

MGR：MySQL Group Replication。是MySQL官方在5.7.17版本正式推出的一种组复制机制。主要是解决传统异步复制和半同步复制的数据一致性问题。

由若干个节点共同组成一个复制组，一个事务提交后，必须经过超过半数节点的决议并通过后，才可以提交。引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。MGR依靠分布式一致性协议(Paxos协议的一个变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(方案落地后是否可靠还有待商榷)。

支持多主模式，但官方推荐单主模式：

多主模式下，客户端可以随机向MySQL节点写入数据
单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理。

在这里插入图片描述

优点：

基本无延迟，延迟比异步的小很多
支持多写模式，但是目前还不是很成熟
数据的强一致性，可以保证数据事务不丢失

缺点：

仅支持innodb，且每个表必须提供主键。
只能用在GTID模式下，且日志格式为row格式。

适用的业务场景：

对主从延迟比较敏感
希望对写服务提供高可用，又不想安装第三方软件
数据强一致的场景

分库分表

分库分表就是业务系统将数据写请求分发到master节点，而读请求分发到slave 节点的一种方案，可以大大提高整个数据库集群的性能。但是要注意，分库分表的一整套逻辑全部是由客户端自行实现的。而对于MySQL集群，数据主从同步是实现读写分离的一个必要前提条件。

作用

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。

例如：微服务架构中，每个服务都分配一个独立的数据库，这就是分库。而对一些业务日志表，按月拆分成不同的表，这就是分表。

方式

垂直分片：按照业务来对数据进行分片，又称为纵向分片。他的核心理念就是专库专用。在拆分之前，一个数据库由多个数据表组成，每个表对应不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库或表中，从而将压力分散至不同的数据库或表。

垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对业务需求快速变化的。而且，他也无法真正的解决单点数据库的性能瓶颈。垂直分片可以缓解数据量和访问量带来的问题，但无法根治。如果垂直分片之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。

水平分片：又称横向分片。相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段(或某几个字段)，根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。

常用的分片策略有：

策略	优点（或介绍）	缺点
取余\取模	均匀存放数据	扩容非常麻烦
按照范围分片	比较好扩容	数据分布不够均匀
按照时间分片	比较容易将热点数据区分出来
按照枚举值分片	例如按地区分片
按照目标字段前缀指定进行分区	自定义业务规则分片

水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。

缺点

虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但是分布式的架构在获得收益的同时，也引入了非常多新的问题。

事务一致性问题：原本单机数据库有很好的事务机制能够帮我们保证数据一致性。但是分库分表后，由于数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。（最怕的就是事务一致性问题）
跨节点关联查询问题：在没有分库时，我们非常容易就可以进行跨表的关联查询。但是在分库后，表被分散到了不同的数据库，就无法进行关联查询了。这时就需要将关联查询拆分成多次查询，然后将获得的结果进行拼装。
跨节点分页、排序函数：跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。这时非常容易出现内存崩溃的问题。
主键避重问题：在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。
公共表处理：实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。这一类表一般就需要在每个数据库中都保存一份，并且所有对公共表的操作都要分发到所有的分库去执行。
运维工作量：面对散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作都变得非常繁重。对于每一次数据读写操作，他们都需要知道要往哪个具体的数据库的分表去操作，这也是其中重要的挑战之一。

什么时候需要分库分表

阿里巴巴规范手册第五章MySQL数据库第一节建表规范第14条：

14.【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

考虑到分库分表需要对数据进行再平衡，所以如果要使用分库分表，就要在系统设计之初就详细考虑好分库分表的方案，这里要分两种情况。

一般对于用户数据这一类后期增长比较缓慢的数据，一般可以按照三年左右的业务量来预估使用人数，按照标准预设好分库分表的方案。

而对于业务数据这一类增长快速且稳定的数据，一般则需要按照预估量的两倍左右预设分库分表方案。并且由于分库分表的后期扩容是非常麻烦的，所以在进行分库分表时，尽量根据情况，多分一些表。最好是计算一下数据增量，永远不用增加更多的表。

另外，在设计分库分表方案时，要尽量兼顾业务场景和数据分布。在支持业务场景的前提下，尽量保证数据能够分得更均匀。

最后，一旦用到了分库分表，就会表现为对数据查询业务的灵活性有一定的影响，例如如果按userId进行分片，那按age来进行查询，就必然会增加很多麻烦。如果再要进行排序、分页、聚合等操作，很容易就扛不住了。这时候，都要尽量在分库分表的同时，再补充设计一个降级方案，例如将数据转存一份到ES，ES可以实现更灵活的大数据聚合查询。

常见的分库分表组件

由于分库分表之后，数据被分散在不同的数据库、服务器。因此，对数据的操作也就无法通过常规方式完成，并且它还带来了一系列的问题。好在，这些问题不是所有都需要我们在应用层面上解决，市面上有很多中间件可供我们选择。

shardingsphere

shardingsphere官网：https://shardingsphere.apache.org/document/current/cn/overview/

Sharding-JDBC是当当网研发的开源分布式数据库中间件，他是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和 Sharding-Sidecar（计划中）这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

mycat

mycat 官网地址： http://www.mycat.org.cn/

基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀的架构和性能以及众多成熟的使用案例使得MYCAT一开始就拥有一个很好的起点，站在巨人的肩膀上，我们能看到更远。业界优秀的开源项目和创新思路被广泛融入到MYCAT的基因中，使得MYCAT在很多方面都领先于目前其他一些同类的开源项目，甚至超越某些商业产品。

DBLE 官网地址：https://opensource.actionsky.com/

该网站包含几个重要产品。其中分布式中间件可以认为是MyCAT的一个增强版，专注于MySQL的集群化管理。另外还有数据传输组件和分布式事务框架组件可供选择。

关闭主从

部署环境有时需要更换取消主从机制或者更换备机，需要将之前的主备关系解除，现梳理其一般性流程：

停止slave
停止master

slave

首先需要停止slave，登录进入MySQL从节点之后，使用SQL语句stop slave;停止slave，然后使用SQL语句reset slave all;清除slave信息，接下来我们查看当前状态，如果是以下的情况说明解除从节点成功：

mysql> show slave status\G

Emptyset (0,00 sec)

因为我的从节点所在服务器过期了，毕业设计也结束了，我就干脆不理这个从服务了，只需解除主服务，所以这里就没有截图了。

master

解除完所有的从服务之后，接下来解除主服务：

登录进入MySQL主节点之后，使用命令reset master;清除master上主从信息，此时将删除日志索引文件中记录的所有binlog文件，创建一个新的日志文件，起始值从000001 开始（补充一下上面遗漏的，命令reset master;用于进行搭建主从库时，进行主库binlog初始化工作），值得注意的是，我之所以先解除从服务，就是因为reset master; 不能用于有任何slave 正在运行的主从关系的主库。因为在slave 运行时刻 reset master; 命令不被支持，reset master; 将master 的binlog从000001 开始记录，slave 记录的master log 则是reset master; 时主库的最新的binlog，从库会报错无法找的指定的binlog文件。
如果想彻底清除主从的机制，可以修改配置文件，删除所有主从相关的配置项，然后重启mysql即可。

如图所示：
解除主节点

JavaDevelopmentDM

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
2
评论
とあるMySQLの主从架构

MySQL搭建主从复制和读写分离。MySQL服务的主从架构一般都是通过binlog日志文件来进行的，在主服务上打开binlog记录每一步的数据库操作，然后从服务上会有一个IO线程，负责跟主服务建立一个TCP连接，请求主服务将binlog传输过来。这时主库上会有一个IOdump线程，负责通过这个TCP连接把binlog日志传输给从库的IO线程。接着从服务上另外一个SQL线程会读取relay日志里的内容，进行操作重演，达到还原数据的目的。我们通常对MySQL做的读写分离配置就必须基于主从架构来搭建。
复制链接

扫一扫

专栏目录