MySQL 学习篇（五）MySQL高可用架构设计——复制工作方式
目录
（一）MySQL二进制日志复制的工作方式及原理
（二）MySQL基于日志点——工作大体步骤解析
（二）MySQL基于日志点——在Linux上的操作实战
（二）MySQL基于日志点——主从服务器结构分析
（二）MySQL基于日志点——特点
（二）MySQL基于日志点——推荐同片文章
（三）MySQL基于GTID——工作方式及原理
（三）MySQL基于GTID—— 什么是GUID
（三）MySQL基于GTID——启动GTID的基本参数解析
（三）MySQL基于GTID——启动GTID的其他参数解析
（三）MySQL基于GTID——在Linux上的操作实战
（四）MySQL复制拓扑结构——前言
（四）MySQL复制拓扑结构——定义与优点
（四）MySQL复制拓扑结构——情景应用
（四）MySQL复制拓扑结构——常用复制的拓扑架构
MySQL复制性能优化
MySQL复制常见问题处理
什么是高可用架构
MMM架构
MHA架构
读写分离和负载均衡介绍
MaxScale实例演示
-
（一）MySQL二进制日志复制的工作方式及原理
- 大图
- 1 主将变更写入二进制日志
首先主服务器对数据的修改记录到二进制日志中，所以使用MySQL复制的功能必须开启二进制日志，需要注意的是二进制日志在一些版本中，默认的是并不会开启的，所以在进行数据库服务器配置时一定要注意，是否开启了二进制日志，如果一开始没有开启，在以后需要使用必须要重新启动服务器才行，而数据库服务器的启动，往往会对这种业务造成很大的影响，我们最好在一开始进行数据库配置的时候把二进制启动起来。
- 2 从读取主的二进制日志变更并写入到relay_log中
复制的第二步是由从服务器完成的，从服务器会从指定的位置，开始读取主服务器的二进制日志的信息，并把读到的二进制日志保存到从服务器，本地的终极日志也就是relay_log中。
- 2 从读取主的二进制日志变更并写入到relay_log中
完成这个二进制日志传输过程：
首先，要在从服务器上的启动一个工作线程池【I/O线程】，这个I/O线程会跟主库建立客户端连接，然后在主库上启动一个特殊的二进制转储现场【binlog dump】，从库上I/O线程通过这个二进制，转储线程读取主库上的二进制日志中的事件，它不会对事件进行轮洵，如果该线程追赶上了一种主库，那么他将进入sleep状态，直到主库发送信号通知其又有了新的事件产生时，才会被唤醒。
那么这个终极日志的格式和二进制日志的是完全相同的，我们也可以使用前面binlog的工具，读取终极日志中的内容。
问：如何从什么位置开始读取主库的二进制日志的方法有哪些？
答：基于日志点的复制和基于GTID的复制。
- 3 在从上重放relay_log中的日志
从服务器读取中终极日志中的事件，并在从数据库对这些事件进行重放，对于这一步呢，由从服务器上的SQL线程来完成，这种由SQL线程所执行的事件也可以通过配置的选项，来决定是否进入到从服务器的二进制日志中，根据二进制日志的接口格式都不同，这种重放的方式也会有不同，基于SQL段的日志是在从库上重新执行记录的SQL语句，而基于行的日志，则是在从库上，直接引用的数据行的修改。
-
（二）MySQL基于日志点——工作大体步骤解析
（一）具体章节内容介绍方向
- 初始化服务器数据
- 启动复制连路
- Linux下的操作步骤
（二）具体章节内容操作和简介
基于日志点的复制配置步骤
- 1 在主DB服务器上创建复制账号
CREATE USER 'repl' @' IP段' identified by 'PassW0rd';
-- repl：账号名称，replication 复制的简写
--IP段：指定这个账号可以使用的网段【建议大家只对复制账号，只对存在从服务器的网段来进行授权，否则可能就会被人利用来获取二进制日志，也有可能造成数据库信息的泄露】
--PassW0rd：要根据我们的密码规范来进行修改
- 2 用户授权，对于复制用户来说只要授予replication slave的权限就可以了，授权的语句：
GRANT REPLICATION SLAVE ON *.* TO 'repl' @ 'IP段';
解析：使用grant语句来进行授权，权限只有replication slave，授权用户就是我们上面所建立的repl用户。
- 3 完成授权之后我们要对主从服务器进行配置
- 配置主数据库服务器
bin_log = mysql-bin
解析：用于启动Mysql的二进制日志，并且指定二进制日志的名字，这里是mysql-bin开头的一系列的文件，我们也可以使用这个参数来指定二进制日志存放的目录，启动装好一定要有写入的权限，否则在启动MySQL的服务器的时候就会报错。
serve_id = 1000
解析：是一个动态参数，这就意味着我们可以使用set命令来对这个参数进行配置，注意事项就算使用set命令配置之后，我们也一定要记得在配置文件中做相同的修改，否则下次重启服务之后这个配置就没有了，这样就可能会造成复制的异常，另外要注意的是，这个ID的值在整个复制集群中必须是唯一的，所以建议大家使用一个统一的规则来对这个参数值来进行设置，比如可以使用主机IP地址的后几段来作为这个是serve_id的值
- 配置从数据库服务器
relay_log = mysql-relay-bin
解析：指定了终极日志的名字，只要启动了主从重复这个参数，默认就会启动
问：但是为什么这个参数还一定要进行配置呢？
答：是因为在默认的情况下，这个参数的默认这名字是我们的主机的名字。如果人为更改了这个主机名，再重新启动从服务器的复制连路时，就会找不到终极日志，从而中断主从复制的连路，所以一定要把终极日志的名字固定另外两个参数的
log_slave_update = on [可选]
解析：是否把SQL线程从放到终极日志，记录到从服务器本机的二进制日志中，如果后续要做连路复制，也就是把从服务器当作其他服务器的主服务器来进行复制时，这个参数的就是必须要配置的。
read_only = on [可选]
解析：安全配置参数可以阻止任何没有super权限的用户，对开启了这个选项的数据库进行写操作，使用这个参数可以保证由于程序的错误配置而造成的从服务器上对数据修改的情况不会发生【建议大家从服务器上启用这个参数】
- 3 初始化从服务器数据
mysqldump --master-data=2 -single-transaction
解析：MySQL有官方所提供数据库备份工具mysqldump，这个工具所做的是逻辑备份，也就是说使用这个工具对Mysql数据库进行备份时，会把数据库中所有的数据库对象找出来，存储为一个sql文件，为了保证数据一致性的。
在使用这个工具时，工具对InnoDB表进行备份时，要加上-single-transaction参数；如果是混合使用InnoDB表和MyISAM表则需要加上--lock-all-tables参数，从这两个参数中了，大家可以看出来，使用这个工具进行备份，是需要对所备份的表加锁的，就会影响数据库的这种并发性，在一个访问非常频繁的系统中使用这个工具，会造成大量的阻塞。
--master-data用于记录在备份时，主库当前的二进制日志文件和二进制日志文件的这个拼音亮的信息，只有记录了这两个值，我们才可以在从库上使用，称是master to命启动主从复制的连路。
xtrabackup --slave-info
解析：另一种常用的数据库备份工具，提供了MySQL数据库的热备工具，对于全部使用InnoDB存储引擎数据库来说，是一种最好的备份方式了，对于InnoDB存储引擎其能够在备份时，不堵塞服务器的操作，因此可以在不影响主库的情况下设置从库，但是对于混合使用了InnoDB和其他存储引擎的数据库，使用这个工具，备份非InnoDB存储引擎的表时，同样会对这些标准进行锁操作，建议大家在数据库中只使用InnoDB存储引擎的表。
--slave-info：也可以记录在备份时，主数据库服务器的二进制日志的信息，以及当前日志的偏移量的信息。
- 4 启动复制连路
CHANGE MASTER TO MASTER_HOST='master_host_ip',
MASTER_USER= 'repl' ,
MASTER_password= 'PassW0rd' ,
MASTER_LOG_FILE= 'mysql_log_file_name' ,
MASTER_LOG_POS=4;
解析：进行完从数据库的初始化之后，我们就可以准备启动这个复制连路了，这是在从服务器上进行操作的，我们可以使用上面SQL语句告诉备库，从主数据库二进制日志的什么位置开始同步数据。建立一个普通的基于日志的复制连路，只要指定以上参数就已经足够了。
master_host：主数据库服务器的IP地址；
master_user master_password：就是我们在第一步时，建立用于复制的数据库的名字和密码；
master_log_file master_log_pos：比较重要的一个东西了。
问：这两个参数的值的来源是哪里？
答：在我们上面备份的数据库文件中，也就是备库要从主库的什么位置，开始同步二进制日志的文件名和偏移量。
-
（二）MySQL基于日志点——在Linux上的操作实战
在两台数据库服务器的Mysql服务器上进行操作{192.168.60.136 主 N1 / 192.168.60.137从N2 }【注意步骤序号】：
- 1.创建复制用户和授权
mysql> create user repl@'192.168.60.%' identified by '123456';
Query OK, 0 rows affected (0.01 sec)
mysql> grant replication slave on *.* to repl@'192.168.3.%';
Query OK, 0 rows affected (0.00 sec)
- 2.添加配置参数到my.cnf
# BINARY LOGGING #
log_bin = mysql-bin # ps：注意此文件目录必须存在，不然service mysqld restart重启失败
max_binlog_size = 1000M
binlog_format = row
expire_logs_days = 7
sync_binlog = 1
# Replice #
server-id = 1
# relay_log = /home/mysql/sql_log/mysqld-relay-bin
# /home/mysql/sql_log/mysqld-relay-bin 文件夹必须存在 从库配置要求相同log_bin：二进制日志存放路径
max_binlog_size：当前的日志大小达到max_binlog_size,还会自动创建新的二进制日志
binlog_format：binlog日志格式，mysql默认采用statement
expire_logs_days：超过保留时间的binlog日志会被自动删除
sync_binlog：sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。
- 4.主服务N1器建立crn数据库
link6.创建库、表和插入、修改数据
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| crn |
| mysql |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)
- 5.主从数据库的初始化（mysqldump数据库备份--建议使用xtrabackup热备份不会对生成环境数据库有影响）
# 主从版本一致*备份所有数据库
[root@localhost ~]# mysqldump --single-transaction --master-data --triggers --routines --all-databases >>all.sql
[root@localhost ~]#
# 主从版本不一致*仅备份业务数据库
[root@localhost ~]# mysqldump --single-transaction --master-data --triggers --routines --all-databases -uroot -p>>all.sql
Enter password:
--密码是空
-- 为什么？
-- 因为：连系统库一起备份很可能造成，由于系统数据库结构不一样，而造成这个日志的bug。
--master-data：指定备份主数据库
--triggers：备份触发器
--all-databases：备份所有数据库
如果主从数据库的版本是一致的，就可以备份所有数据库包括系统数据库Mysql
- 9.all.sql内容（保存日志名称和偏移量）
- 6.备份完主N1数据库，我们scp命令把要拷贝到从服务器上N2 root目录下，然后进行数据初始化
# N1
[root@localhost ~]# scp all.sql [email protected]:/root
[email protected]'s password:
all.sql 100% 632KB 33.3MB/s 00:00
# 登陆服务器密码
# N2
[root@localhost ~]# ls
all.sql anaconda-ks.cfg mysql-community-release-el7-5.noarch.rpm
- 3.从上N2配置的检查
# BINARY LOGGING #
log_bin = mysql-bin # ps：注意此文件目录必须村才，不然service mysqld restart重启失败
max_binlog_size = 1000M
binlog_format = row
expire_logs_days = 7
sync_binlog = 1
# Replice #
server-id = 2
# relay_log = /home/mysql/sql_log/mysqld-relay-bin- 7.从服务器N2在主服务器传输完all.sql之后查看是否已经传输完毕
[root@localhost ~]# ls
all.sql anaconda-ks.cfg mysql-community-release-el7-5.noarch.rpm
- 8.从服务器N2数据初始化【将all.sql文件导入到Mysql服务器中】
mysql> source /root/all.sql
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| crn |
| mysql |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)
# 关闭slave（如果你以前配置过主从的话，一定要先关闭）
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
# 开始配置：
mysql> CHANGE MASTER TO MASTER_HOST='192.168.60.136',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=519;
Query OK, 0 rows affected, 2 warnings (0.10 sec)参数解释：MASTER_HOST ：设置要连接的主服务器的ip地址
MASTER_USER ：设置要连接的主服务器的用户名
MASTER_PASSWORD ：设置要连接的主服务器的密码
MASTER_LOG_FILE ：设置要连接的主服务器的bin日志的日志名称，即第3步得到的信息
MASTER_LOG_POS ：设置要连接的主服务器的bin日志的记录位置，即第3步得到的信息，（这里注意，最后一项不需要加引号。否则配置失败）
- 9.查看N2是否配置成功
mysql> show slave status;
# 或者 show slave status\G;
- 10.启动N2
mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)- END(I/O 、SQL进程都能启动了)
-
（二）MySQL基于日志点——主从服务器结构分析
-- N2
mysql> show processlist;
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+
| 7 | root | localhost | NULL | Query | 0 | init | show processlist |
| 8 | system user | | NULL | Connect | 239 | Connecting to master | NULL |
| 9 | system user | | NULL | Connect | 239 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL |
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)
# 从服务器N2建立了，两个复制有关的线程，一个是I/O线程，一个是SQL线程。
--N1
mysql> show processlist \G;
*************************** 1. row ***************************
Id: 2
User: root
Host: localhost
db: NULL
Command: Binglog Dump
Time: 0
State: init
Info: show processlist
1 row in set (0.00 sec)
# 主服务器上建立了binlog dump线程，用于读取主数据的二进制日志信息。
-
（二）MySQL基于日志点——特点
其自身的优点、缺点。
- 基于日志点复制的优点
- 最早支持的一种复制技术bug会比较少
- 对复制集群中所有SQL语句没有任何的限制，特别是使用基于行的复制的情况下，对所执行的SQL没有任何的要求，大家不要认为这是理所当然的，后面的我们在介绍基于GTID的复制时就会发现，基于GTID的复制中并不是SQL都可以使用的
- 因为已经被使用了很长时间，所以对于一些故障的处理大家都很熟悉，比如：很容易的忽略从从库(N2)中传过来的某个事件，而使主库的主从同步继续执行，而这一点在基于GTID的复制并不容易实现
- 基于日志点复制的缺点
- 最大的缺点是在故障转移时，很难找到从库对于新的主库所同步的新的二进制日志文件的偏移量，这在一组多从的环境中尤为的困难，如果主库发生了宕机，我们要从多个从库中找出一个新的主库，而其他的从库要对这个新的主库进行重新同步，由于每个服务器的二进制日志的文件都是独立存在的，所以很难找到其他从库应该和新的主库进行同步的日志点，而这一点在我们后面的高可用部署的时候，会显得非常的重要，到时候大家会有非常深刻的体会。
-
（二）MySQL基于日志点——推荐同片文章
推荐文章：https://www.cnblogs.com/superfat/p/5267449.html
-
（三）MySQL基于GTID——工作方式及原理
- 1 版本要求
基于GTID的复制，是从MySQL5.6开始支持的一种新的复制方式，其实现方式同基于日志的复制，存在着很大的差异。
- 1 基于日志的复制图示如下
分析：在基于日志的复制中，从服务器连接到主服务器并告诉主服务器，要从哪个二进制日志的偏移量开始进行增量同步，那么这时如果我们所指定的日志偏移量不对，就很有可能造成事务的遗漏或者是重复执行某些事务，从而造成主动复制的不一致。
- 2 基于GUID的复制图示如下
分析：在基于GTID的复制中，首先从服务器会告诉主服务器，已经在从服务器上执行完了的GTID值，然后主库会把所有没有在这个从库上执行的事务，发送到从库上再进行执行，并且使用及GTID的复制可以保证同一个事务，只在指定的从库上执行一次。
这样就避免了上面所说的，由于是由于日志偏移量的问题而产生的数据不一致的问题。
-
（三）MySQL基于GTID—— 什么是GUID
分析：也就是全局事务ID，其保证了每一个在主上提交的事务在复制集群中可以生成唯一的ID，一个GTID是由两部分组成的，包括source_id和transaction_id。
source_id：是执行事务主库的server uuid的值，其是在Mysql首次启动时自动生成，并且保存在数据库的数据目录auto.cnf中，生成server uuid的算法可以保证每一个MySQL实例的UUID值都是不同的，而事务ID则是从1开始自增的序列，表示事务是在这个主库执行的第几个事务物，MySQL保证事务与GTID之间的是1:1的映射关系。
问：基于GTID的复制的步骤和原来的基于日志点的复制有什么不同？
-
（三）MySQL基于GTID——启动GTID的基本参数解析
- 1 在主DB服务器 N1 上建立复制账号
问：为什么不能手动在其他的从服务器 N1X 上 建立相同的账号？
答：因为基于GTID的复制会把所有没有在从服务器上，执行的事务都同步到从上去。
问：如果手动建立账号会有什么后果？
答：启动复制连路时出现错误。
- 2 配置主数据库服务器
问：基于GTID的复制的步骤和原来的基于日志点的复制最大的区别？
答：配置主数据库服务器
bin_log：是必须的，无论是基于日志点的复制还是基于GTID复制，都是基于MySQL二进制日志所进行的，只要使用MySQL复制功能，就一定要启动这个blog日志；
分析：参数设置存储到log目录中，而不是使用默认的数据目录，存放二进制日志目录和数据目录分开，是个很好的习惯，特别是如果可以把日志和数据分别放在不同的磁盘分区上就更好了，这样不但可以避免由于日志的增长，把数据目录所在磁盘分区占满的情况，还可以获得额外的一些I/O型的提升。
server_id：和基于日志点的复制是一样的，要求复制的集群中是唯一的，虽然满MySQL 5.6版本之后在基于GTID复制中会自动使用主机的server uuid来替代这个值，but server_id 还是必须要设置的，同样要保持在这个复制集中唯一。
gtid_mode：基于日志点的复制中没有使用的，决定了是否启用基于GTID模式，在启动这个选项后面，在间隙中会额外地记录每一个事务的gtid标识符，所以要使用GTID的复制，我们就必须要设置这个参数。
-
（三）MySQL基于GTID——启动GTID的其他参数解析
（一）配置主数据库服务器
log-slave-update：强制GTID一致性，在从服务器中记录主服务器传过来的修改日志所使用的，在Mysql 5.7版本之前无论是否记录发送过来的日志，只要想使用GTID模式就必须开启此参，会增加从Mysql的I/O负载。
版本分析：在MySQL 5.7版本中已经被去掉了，所以由此看来GTID模式更适合在Mysql 5.7中使用，当前Linux演示系统就是基于Mysql 5.7来进行的，所以我们并不会启动log-slave-update参数。
如果是在Mysql 5.6 或者Mysql 5.5中使用GTID的复制，记得一定要启动log-slave-update，否则GTID模式是无法启动。
分析：其中强制GTID的一致性的参数，用于保证启动GTID后事务的安全，使用这个参数后，也会对我们使用Mysql带来一些变化，其中的下面的命令，在启动这个参数之后就无法再使用了：
- 首先之前的我们可以使用create table ... select 语句，通过查询来建立一个新的表，一旦启动此参这种方法就无法再使用了，我们只能先建立表结构，然后再使用insert into ... select 语句，把数据插入到表中；
- 其次在事务中，如果使用了create temporay table 建立临时表，此操作使用了关联更新时，同时更新事务表和事务表的操作都会报错。
（二）配置从数据库服务器
分析：最后两个建议，指定的从服务器连接主服务器的信息，以及终极日志相关信息的存储方式，默认的是存储在文件中的，我们可以通过上面的配置，来把这些信息分别记录到Mysql数据库的slave master.info和relay-log.info中，这两个和大多数的Mysql系统表是不同的，是使用InnoDB存储引擎，这样做的好处是当出现数据库崩溃时，我们可以利用InnoDB事务引擎的特点，对这两个表的信息进行崩溃恢复，保证从服务器可以从正确的位置重新开始同步数据。
（三）从服务器的初始化操作
对从数据库初始化的方法基本和基于日志点的复制的是相同的，只不过在启动了GTID的模式后，在备份中，所记录的就不是备份时的二进制日志的文件名和偏移量了，而是记录备份时最后的事务的GTID值。
（三）启动GTID的复制
从服务器上使用change master命令，使用了MASTER_AUTO_POSITION告诉从服务器使用基于GTID的复制方式
-
（三）MySQL基于GTID——在Linux上的操作实战
-
bullabulabula.........................数据库服务器了，和之前也是基于日志的呢，福建的是同样的，这两天我们再来看那段rap，应该是，192.168点3.1百，另一个呢是3.2101，这跟之前我们的数据库呢是一样的，在我这里呢，我们就按照我们的步骤来一次的，对这个，说句话进行配置，首先呢，由于我们之前的已经建立了我们的这个复制账号，所以来到这里我们就不用再重复的建立，复制用户了，我们大家可以来看一下，
-
-
（四）MySQL复制拓扑结构——前言
Mysql主从复制的拓扑结构非常的灵活，如果不考虑其他因素，可以给一个主库设置任意多个从库，也可以是一个从库，其他从库的主库，但是在Mysql 5.7之前的版本中，存在一个限制一个从库只能有一个主库，但是这个限制在5.7之后的版本已经打破，支持已从多补的拓扑架构，可以设计出更加灵活的主从复制拓扑。
-
（四）MySQL复制拓扑结构——定义与优点
一主多从复制拓扑概念
- 和一主一从拓扑结构十分相似，只是在一个主库的上面连接多个从库，每一个从库的配置方法也和前面 一主一从拓扑架构中，从服务器的配置方式完全相同。
一主多从复制拓扑优点
- 1 配置简单
配置简单，非常方便地比较不同从库，存放的是事件在主库二进制位置，对主库要进行停机维护时，就可以利用这种特性方便的进行主从切换。
1、先把主库设置为只读，在所有从库同步完主库的数据后
2、从多个备选中选出一个新的主库，直接进行切换就可以了
分析：所有从库中读取到的主库，二进制日志的位置都是相同的，他们的数据也都是一样。
- 2 可以用多个从库分担读负载
由于所有的从库都是连接到的主库，所以和其他级联拓扑相比，个个从库上的延迟几乎都相同。
可以利用多个从库来分担主库的读负载，而不用担心程序连接到不同从库上获得的数据不同的问题，当然由于Mysql复制是异步的，所以并不能保证所有从库的数据在同一时间点都是完全一致的，但是这种拓扑却可以使这种数据的差异最小化。
（四）MySQL复制拓扑结构——情景应用
- 按业务来分割【使不同业务负责不同的业务查询，这样做的好处是什么？我们可以根据不同业务特点，使用不同的存储引擎和索引，最常见的是分割前后台的查询，因为业务的前台使用的查询和后台使用的查询的往往有很大的差距，比如前台使用查询，通常所获取的数据量都是比较小的，要求查询的速度比较快的能返回，而后台的统计类查询，通常读取的数据量非常的多，同时对于查询的响应时间，要求并不像前台那么敏感。我们就需要对前后台的查询的建立不同的索引，把前后台的查询分别指定不同的从库上，可以方便的进行索引优化，同时也可以使得后来的查询不会影响到前台的业务】
- 一台从库放到远程的IDC中，用作灾备恢复【这并不是一主多从拓扑架构特有用途，下面我们所介绍的所有主从拓扑架构中的都可以用于这种用途，只不过由于在一种多从中，所有的从都是直接从主机连接的，所以从上的复制的延迟，通常说比其他的拓扑更小，
- 分担主库的读负担，但由于主库上的写还是会被复制到所有的从库上的，所以Mysql复制架构并不能够分担写负载。
问：想分担主库的写负载的唯一方法是什么呢？
答：就是对主户进行分库分表操作，把拆分后的主库分别放到不同的物理服务器上去，如何分库分表后面会有讨论。
-
（四）MySQL复制拓扑结构——常用复制的拓扑架构
- 主-主复制拓扑
- 主主复制可以称之为双主复制，是由两台服务器组成，其中的每一台能和另一台服务器都是互为主从的，由于Mysql 5.7之前一个从库只能有一个主户，所以组成这种架构也就是需要两个Mysql实例，其拓扑结构图如下图：
- pic
分析：上图的拓扑复制流，由于两台服务器的server id是不同的，所以不会担心循环复制的这种问题发生，从这张图中我们还可以看到这种架构有两种使用方式：一种是在两个主中，只有一个主会对外提供服务，另一个在提供服务的主出现问题时才会对外提供服务这种模式，称之为主备的主主复制模式。
两个组同时对外提供服务，这种模式称之为主主复制的主从复制模式，千万不要认为，这种模式可以分担主库的写负载，实际上不管写发生在哪一个主上，都会被复制到另外一个主上，然后重新执行，所以这种模式的也并不能用于分担写负载。
-
-
MySQL复制性能优化
-
-
MySQL复制常见问题处理
-
-
什么是高可用架构
-
-
MMM架构
-
-
MHA架构
-
-
读写分离和负载均衡介绍
-
-
MaxScale实例演示
-