深入探索MySQL主从架构与读写分离：提升数据安全和性能的实战指南

一、实验目的与环境

实验目的：

MySQL是互联网中广泛使用的开源数据库。在开发时，我们通常使用单机服务，但在生产环境中，由于数据量庞大和高安全性要求，单机MySQL无法满足这些需求。因此，生产环境中的MySQL需要建立主从复制架构和基于工具的高可用架构，同时实现读写分离。对于极大的数据量，还需实现分库分表。这些架构的建立相对复杂，通常由专业运维人员完成。本次实验旨在让大家理解MySQL在生产环境下的架构，并应用于实际项目中，也为学习ShardingSphere分库分表做准备

实验环境：

1、Linux服务器两台：centos7
2、mysql版本：mysql-8.0.20

二、基础环境介绍

两台服务器，均安装CentOS7。
1、 192.168.232.128 作为mysql主节点部署
2、 192.168.232.129 作为mysql从节点部署
mysql版本：mysql-8.0.20
为了便于使用，两个mysql服务需要打开远程登录权限，开启方式需要在本机登录 mysql，执行以下语句。

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

三、搭建主从集群

1、理论基础

主从架构的作用是缓解MySQL的数据存储和访问压力。这一架构不仅对提高系统性能至关重要，还对确保数据安全发挥着重要作用。

数据安全：通过在主服务增加一个备份，主从架构提升了数据的安全性。基于这个目的，可以构建标准的主从架构，或者更进一步，搭建互主架构以进一步增强安全性。
读写分离：考虑到大多数JAVA业务系统中读操作远多于写操作，主从架构使得从服务可以承担读请求，而主服务专注于处理写请求。这不仅减轻了数据库的访问压力，也提高了整体性能。但要注意，实现有效的读写分离还需要依赖特定的中间件，例如ShardingSphere。
故障转移与高可用性：在主服务发生故障时，从服务可以迅速转变为主服务，保证数据的连续可读写。要实现这种高可用性，主从数据同步是基础，但也需要依赖其他中间件，如MMM、MHA、MGR。在数据库访问压力不大的项目中，尽管读写分离可能不是必需的，但搭建主从架构和保证高可用性是基本要求。

2、同步的原理

MySQL的主从架构通常通过binlog日志文件进行数据同步。具体步骤如下：

在主服务上，开启binlog记录每一步的数据库操作。
从服务上有一个IO线程，负责与主服务建立TCP连接，请求主服务传输binlog。
主服务上有一个IO dump线程，通过TCP连接将Binlog日志传输给从库的IO线程。
从服务的IO线程将读取到的binlog日志数据写入自己的relay日志文件中。
从服务上的SQL线程读取relay日志中的内容，进行操作重演，以还原数据。

这种主从架构通常用于MySQL的读写分离配置。

MySQL的binlog不仅可以用于主从同步，还可用于缓存数据同步等情景。例如，Canal可以模拟一个从节点，向MySQL发起binlog同步，然后将数据传输到Redis、Kafka等其他组件，实现实时数据流转。

在搭建主从集群时，有两个必要的要求：

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

3、搭建主从集群

3.1 配置master主服务器

首先，配置主节点的mysql配置文件： /etc/my.cnf 这一步需要对master进行配置，主要是需要打开binlog日志，以及指定severId。我们打开MySQL主服务的my.cnf文件，在文件中一行server-id以及一个关闭域名解析的配置。然后重启服务。

[mysqld]
server-id=47
#开启binlog
log_bin=master-bin
log_bin-index=master-bin.index
skip-name-resolve
# 设置连接端口
port=3306
# 设置mysql的安装目录
basedir=/usr/local/mysql
# 设置mysql数据库的数据的存放目录
datadir=/usr/local/mysql/mysql-files
# 允许最大连接数
max_connections=200
# 允许连接失败的次数。
max_connect_errors=10
# 服务端使用的字符集默认为UTF8
character-set-server=utf8
# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB
# 默认使用“mysql_native_password”插件认证
#mysql_native_password
default_authentication_plugin=mysql_native_password

重启MySQL服务， service mysqld restart

然后，我们需要给root用户分配一个replication slave的权限。

#登录主数据库
mysql -u root -p
GRANT REPLICATION SLAVE ON *.*TO 'root'@'s';
flush privileges;
#查看主节点同步状态：
show master status;

在实际生产环境中，通常不会直接使用root用户，而会创建一个拥有全部权限的用户来负责主从同步。

这个指令结果中的File 和Position记录的是当前日志的binlog 文件以及文件中的索引。

而后面的Binlog_Do_DB和Binlog_Ignore_DB这两个字段是表示需要记录binlog 文件的库以及不需要记录binlog文件的库。目前我们没有进行配置，就表示是针对全库记录日志。这两个字段如何进行配置，会在后面进行介绍。

3.2配置slave从服务

下一步，我们来配置从服务mysqls。我们打开mysqls 的配置文件my.cnf, 修改配置文件：

[mysqld]
# 主库和从库需要不一致
server-id=48

# 打开MySQL中继日志
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin

# 打开从服务二进制日志
log-bin=mysql-bin

# 使得更新的数据写进二进制日志中
log-slave-updates=1

# 设置3306端口
port=3306

# 设置MySQL的安装目录
basedir=/usr/local/mysql

# 设置MySQL数据库的数据的存放目录
datadir=/usr/local/mysql/mysql-files

# 允许最大连接数
max_connections=20

# 允许连接失败的次数
max_connect_errors=10

# 服务端使用的字符集默认为UTF8
character-set-server=utf8

# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB

# 默认使用“mysql_native_password”插件认证
default_authentication_plugin=mysql_native_password

然后我们启动mysqls的服务，并设置他的主节点同步状态。

#登录从服务
mysql -u root -p;
#设置同步主节点：
CHANGE MASTER TO
MASTER_HOST='192.168.232.128 ',
MASTER_PORT=3306,
MASTER_USER= 'root ',
MASTER_PASSWORD= 'root ',
MASTER_LOG_FILE= 'master-bin.000004 ',
MASTER_LOG_POS=156
GET_MASTER_PUBLIC_KEY=1;
#开启slave
start slave;
#查看主从同步状态
show slave status;
或者用 show slave status \G; 这样查看比较简洁

我们重点关注其中红色方框的两个属性，与主节点保持一致，就表示这个主从同步搭建是成功的。

3.3主从集群测试

测试时，我们先用showdatabases, 查看下两个MySQL 服务中的数据库情况

然后我们在主服务器上创建一个数据库

mysql>create database syncdemo;
Query OK,1 row affected(0.00 sec)

然后我们再用show databases, 来看下这个syncdemo 的数据库是不是已经同步到了从服务。

接下来我们继续在syncdemo 这个数据库中创建一个表，并插入一条数据。

mysql>use        syncdemo;
Database      changed
mysql>create    table    demoTable(id     int    not    null);
Query   Ok, 0    rows    affected(0.02     sec)

mysql>insert     into     demoTable     value(1);
Query   Ok, 1     row    affected(0.01   sec)

然后我们也同样到主服务与从服务上都来查一下这个demoTable 是否同步到了从服务。

从上面的实验过程看到，我们在主服务中进行的数据操作，就都已经同步到了从服务上。这样，我们一个主从集群就搭建完成了。

3.4 集群搭建扩展

在完成这个基本的MySQL主从集群后，我们还可以进行后续的实验：

1、全库同步与部分同步

之前提到，我们目前配置的主从同步是针对全库配置的，而实际环境中，一般并不需要针对全库做备份，而只需要对一些特别重要的库或者表来进行同步。那如何针对库和表做同步配置呢？
首先在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两个参数的作用了。

2、读写分离配置

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

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

3、其他集群方式

我们到这里搭建出了一个一主一从的MySQL 主从同步集群，具有了数据同步的基础功能。而在生产环境中，通常会以此为基础，根据业务情况以及负载情况，搭建更大更复杂的集群。

例如为了进一步提高整个集群的读能力，可以扩展出一主多从。而为了减轻主节点进行数据同步的压力，可以继续扩展出多级从的主从集群。

为了提高整个集群的高可用能力，可以扩展出多主的集群。

我们也可以扩展出互为主从的互主集群甚至是环形的主从集群，实现MySQL多活部署。

搭建互主集群只需要按照上面的方式，在主服务上打开一个slave进程，并且指向 slave节点的binlog 当前文件地址和位置。

3.5、GTID 同步集群

        上面我们搭建的集群方式，是基于Binlog日志记录点的方式来搭建的，这也是最为传统的MySQL集群搭建方式。而在这个实验中，可以看到有一个Executed_Grid_Set列，暂时还没有用上。实际上，这就是另外一种搭建主从同步的方式，即GTID搭建方式。这种模式是从MySQL5.6版本引入的。
        GTID的本质也是基于Binlog来实现主从同步，只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID，全局唯一并且趋势递增，他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID 。
        在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。
        他的搭建方式跟我们上面的主从架构整体搭建方式差不多。只是需要在my.cnf中修改一些配置。

在主节点上：

gtid_mode=on
enforce_gtid_consistency=on
log_bin=on
server_id=单独设置一个
binlog_format=row

在从节点上：

gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=1
server_id=单独设置一个

然后分别重启主服务和从服务，就可以开启GTID同步复制方式。