诶？这项技术又是什么玩意(What)?
 
这项技术为什么会存在？我们已经有那么多解决方案(Method)了，我们为什么要用它(Why)？
 
如果这项技术那么好且我们正好有场景可以用到这项技术，且能使我们的系统得到很乐观的优化，那么我们怎么用呢(How)？
 
大概已经有同学觉得这些问题很熟悉了，是的，这就是黄金全法则提出的三个问题，对于每种新鲜事物我们首先基于这三个问题去了解，更有利于弄清楚事情的本质，端正态度去了解，而不是因为新，因为大家都说好，才要去了解……。说了那么多前奏，我们可以开始了，今天我们就带着黄金圈法则提出的三个问题去看看MySQL数据库复制这项领域技术，然后再结合实际应用扩展一些问题，本文也仅仅是结合自己了解的皮毛以抛砖引玉的态度和大家一起分享。
 
WHAT？
 
MySQL复制使得一台MySQL数据库服务器的数据被拷贝到其他一台或者多台数据库服务器，前者通常被叫做Master，后者通常被叫做Slave。
 
MySQL复制示意图
 
复制的结果是集群(Cluster)中的所有数据库服务器得到的数据理论上都是一样的，都是同一份数据，只是有多个copy。MySQL默认内建的复制策略是异步的，基于不同的配置，Slave不一定要一直和Master保持连接不断的复制或等待复制，我们指定复制所有的数据库，一部分数据库，甚至是某个数据库的某部分的表。
 
MySQL复制支持多种不同的复制策略，包括同步、半同步、异步和延迟策略等。
 
同步策略：Master要等待所有Slave应答之后才会提交(MySql对DB操作的提交通常是先对操作事件进行二进制日志文件写入然后再进行提交)。
 
半同步策略：Master等待至少一个Slave应答就可以提交。
 
异步策略：Master不需要等待Slave应答就可以提交。
 
延迟策略：Slave要至少落后Master指定的时间。
 
MySQL复制同时支持多种不同的复制模式：
 
基于语句的复制，Statement Based Replication(SBR)。
 
基于行的复制Row Based Replication(RBR)。
 
混合复制(Mixed)。
 
WHY?
 
这个问题其实也就是MySQL复制有什么好处，我们可以将复制的好处归结于下面几类：
 
性能方面：MySQL复制是一种Scale-out方案，也即“水平扩展”，将原来的单点负载扩散到多台Slave机器中去，从而提高总体的服务性能。在这种方式下，所有的写操作，当然包括UPDATE操作，都要发生在Master服务器上。读操作发生在一台或者多台Slave机器上。这种模型可以在一定程度上提高总体的服务性能，Master服务器专注于写和更新操作，Slave服务器专注于读操作，我们同时可以通过增加Slave服务器的数量来提高读服务的性能。
 
防腐化：由于数据被复制到了Slave，Slave可以暂停复制进程，进行数据备份，因此可以防止数据腐化。
 
故障恢复：同时多台Slave如果有一台Slave挂掉之后我们还可以从其他Slave读取，如果配置了主从切换的话，当Master挂掉之后我们还可以选择一台Slave作为Master继续提供写服务，这大大增加了应用的可靠性。
 
数据分析：实时数据可以存储在Master，而数据分析可以从Slave读取，这样不会影响Master的性能。
 
HOW?
 
这里我们只介绍一下MySQL的复制是如何工作的，至于配置，网上也有很多相关的介绍，读者具体应用的时候可以再去查阅。我们拿最常用的基于二进制文件的复制来看看。
 
MySQL复制工作示意图
 
请点击输入图片描述
 
请点击输入图片描述
 
MySQL的复制过程大概如下：
 
首先，主库在每次准备提交事务完成数据更新操作之前都会将数据更改操作记录到二进制日志中，这些日志是以二进制的方式记录数据更改的事件。值得一提的是二进制日志中记录的顺序实际上是事务的提交顺序，而非SQL执行语句的顺序。在记录二进制日志之后，主库会告诉存储引擎事务可以提交了。
 
然后，备库会启动一个IO线程，之所以叫做IO线程是因为这个线程专门做IO相关的工作，包括和主库建立连接，然后在主库上启动一个特殊的二进制转储线程，这个转储线程会不断的读取二进制日志中的事件，发送给备库的IO线程，备库的IO线程会将事件记录到中继日志中。
 
备库会有一个叫做SQL的线程被开启，这个线程做的事情是读取中继日志中的DB操作事件在备库执行，从而实现数据更新。
 
总的来说，在发生复制的主库服务器和备库服务器中，一共有三个线程在工作。
 
上面我们已经大概了解的什么是复制？为什么要复制？如何复制？这三个问题了，接下来我们基于上面的介绍，提出一些实际应用可能会发生的问题来思考如何解决。博主自问自答的方式-。-
 
问答环节
 
问题一：通过复制模型虽然读能力可以通过扩展slave机器来达到提高，而写能力却不能，如果写达到瓶颈我们应该怎么做呢？
 
答：我们首先会得出结论，这种复制模型对于写少读多型应用是非常有优势的，其次，当遇到这种问题的时候我们可以对数据库进行分库操作，所谓分库，就是将业务相关性比较大的表放在同一个数据库中，例如之前数据库有A，B，C，D四张表，A表和B表关系比较大，而C表和D表关系比较大，这样我们把C表和D表分离出去成为一个单独的数据库，通过这种方式，我们可以将原有的单点写变成双点写或多点些，从而降低原有主库的写负载。
 
问题二：因为复制是有延迟的，肯定会发生主库写了，但是从库还没有读到的情况，遇到这种问题怎么办？
 
答：MySQL支持不同的复制策略，基于不同的复制策略达到的效果也是不一样的，如果是异步复制，MySQL不能保证从库立马能够读到主库实时写入的数据，这个时候我们要权衡选择不同复制策略的利弊来进行取舍。所谓利弊，就是我们是否对从库的读有那么高的实时性要求，如果真的有，我们可以考虑使用同步复制策略，但是这种策略相比于异步复制策略会大大降低主库的响应时间和性能。我们是否可以在应用的设计层面去避开这个问题？
 
问题三：复制的不同模式有什么优缺点？我们如何选择？
 
答：基于语句的复制实际上是把主库上执行的SQL在从库上重新执行一遍，这么做的好处是实现起来简单，当前也有缺点，比如我们SQL里面使用了NOW()，当同一条SQL在从库中执行的时候显然和在主库中执行的结果是不一样的，注入此类问题可以类推。其次问题就是这种复制必须是串行的，为了保证串行执行，就需要更多的锁。
 
基于行的复制的时候二进制日志中记录的实际上是数据本身，这样从库可以得到正确的数据，这种方式缺点很明显，数据必须要存储在二进制日志文件中，这无疑增加的二进制日志文件的大小，同时增加的IO线程的负载和网络带宽消耗。而相比于基于语句的复制还有一个优点就是基于行的复制无需重放查询，省去了很多性能消耗。
 
无论哪种复制模式都不是完美的，日志如何选择，这个问题可以在理解他们的优缺点之后进行权衡。
 
问题四：复制的工作过程只有三个线程来完成，对于Master来说，写是并发的，也就出现了一个IO线程要把所有并发的数据变更事件记录，这个IO线程会不会累死？当一个Master对应多个Slave的时候，其实在Master中会唤起多个IO线程，这无疑会增加Master的资源开销，如果出现事件堆积，也就是事件太多，来不及及时发送出去怎么办？另外就是Slave那边的IO线程和SQL线程也会有对应主库并发数据变更事件，而Slave方单个线程处理的问题，这个时候Slave线程会不会累死？
 
答：上面的问题确实会发生，上面第一个问题和第二个问题其实是写负载的问题，当事件堆积太多，从库时延就会变大，Slave单SQL线程问题据说有参数可以开启并行操作，这个大家可以确认一下。
 
问题五：针对复制工作过程可能会出现的问题，主库写完二进制日志文件同时都会保存二进制日志的偏移量，但是当断电的时候，二进制日志文件没有刷新到磁盘，主库重新启动之后，从库尝试读该偏移量的二进制日志，会出现读不到的情况，这个问题应该怎么解决？
 
答：首先如果开启了sync_binlog选项，对于innodb同时设置innodb_flush_log_at_trx_commot=1，则可以保证二进制日志文件会被写入磁盘，但MyISAM引擎可能会导致数据损坏。如果没有开启这个选项，则可以通过制定从库的二进制偏移量为下一个二进制日志文件的开头，但是不能解决事件丢失问题。
 
问题六：从库在非计划的关闭或重启时，回去读master.info文件去找上次停止复制的位置，这同样会有一个问题，如果master.info不正确，就会导致复制数据不一致的情况，遇到这个问题怎么办？
 
答：这个问题可以通过两种方式解决，一是控制master.info在从库非计划关闭或重启的时候让master.info能够同步到磁盘，这样下次启动的时候就不会读取错误的信息，这有助于减少错误的发生概率。另外想要找到正确的复制位置是困难的，我们也可以选择忽略错误。
 

 
请点击输入图片描述

 
诶？这项技术又是什么玩意(What)?
 
这项技术为什么会存在？我们已经有那么多解决方案(Method)了，我们为什么要用它(Why)？
 
如果这项技术那么好且我们正好有场景可以用到这项技术，且能使我们的系统得到很乐观的优化，那么我们怎么用呢(How)？
 
大概已经有同学觉得这些问题很熟悉了，是的，这就是黄金全法则提出的三个问题，对于每种新鲜事物我们首先基于这三个问题去了解，更有利于弄清楚事情的本质，端正态度去了解，而不是因为新，因为大家都说好，才要去了解……。说了那么多前奏，我们可以开始了，今天我们就带着黄金圈法则提出的三个问题去看看MySQL数据库复制这项领域技术，然后再结合实际应用扩展一些问题，本文也仅仅是结合自己了解的皮毛以抛砖引玉的态度和大家一起分享。
 
WHAT？
 
MySQL复制使得一台MySQL数据库服务器的数据被拷贝到其他一台或者多台数据库服务器，前者通常被叫做Master，后者通常被叫做Slave。
 
MySQL复制示意图
 
复制的结果是集群(Cluster)中的所有数据库服务器得到的数据理论上都是一样的，都是同一份数据，只是有多个copy。MySQL默认内建的复制策略是异步的，基于不同的配置，Slave不一定要一直和Master保持连接不断的复制或等待复制，我们指定复制所有的数据库，一部分数据库，甚至是某个数据库的某部分的表。
 
MySQL复制支持多种不同的复制策略，包括同步、半同步、异步和延迟策略等。
 
同步策略：Master要等待所有Slave应答之后才会提交(MySql对DB操作的提交通常是先对操作事件进行二进制日志文件写入然后再进行提交)。
 
半同步策略：Master等待至少一个Slave应答就可以提交。
 
异步策略：Master不需要等待Slave应答就可以提交。
 
延迟策略：Slave要至少落后Master指定的时间。
 
MySQL复制同时支持多种不同的复制模式：
 
基于语句的复制，Statement Based Replication(SBR)。
 
基于行的复制Row Based Replication(RBR)。
 
混合复制(Mixed)。
 
WHY?
 
这个问题其实也就是MySQL复制有什么好处，我们可以将复制的好处归结于下面几类：
 
性能方面：MySQL复制是一种Scale-out方案，也即“水平扩展”，将原来的单点负载扩散到多台Slave机器中去，从而提高总体的服务性能。在这种方式下，所有的写操作，当然包括UPDATE操作，都要发生在Master服务器上。读操作发生在一台或者多台Slave机器上。这种模型可以在一定程度上提高总体的服务性能，Master服务器专注于写和更新操作，Slave服务器专注于读操作，我们同时可以通过增加Slave服务器的数量来提高读服务的性能。
 
防腐化：由于数据被复制到了Slave，Slave可以暂停复制进程，进行数据备份，因此可以防止数据腐化。
 
故障恢复：同时多台Slave如果有一台Slave挂掉之后我们还可以从其他Slave读取，如果配置了主从切换的话，当Master挂掉之后我们还可以选择一台Slave作为Master继续提供写服务，这大大增加了应用的可靠性。
 
数据分析：实时数据可以存储在Master，而数据分析可以从Slave读取，这样不会影响Master的性能。
 
HOW?
 
这里我们只介绍一下MySQL的复制是如何工作的，至于配置，网上也有很多相关的介绍，读者具体应用的时候可以再去查阅。我们拿最常用的基于二进制文件的复制来看看。
 
MySQL复制工作示意图
 
请点击输入图片描述
 
请点击输入图片描述
 
MySQL的复制过程大概如下：
 
首先，主库在每次准备提交事务完成数据更新操作之前都会将数据更改操作记录到二进制日志中，这些日志是以二进制的方式记录数据更改的事件。值得一提的是二进制日志中记录的顺序实际上是事务的提交顺序，而非SQL执行语句的顺序。在记录二进制日志之后，主库会告诉存储引擎事务可以提交了。
 
然后，备库会启动一个IO线程，之所以叫做IO线程是因为这个线程专门做IO相关的工作，包括和主库建立连接，然后在主库上启动一个特殊的二进制转储线程，这个转储线程会不断的读取二进制日志中的事件，发送给备库的IO线程，备库的IO线程会将事件记录到中继日志中。
 
备库会有一个叫做SQL的线程被开启，这个线程做的事情是读取中继日志中的DB操作事件在备库执行，从而实现数据更新。
 
总的来说，在发生复制的主库服务器和备库服务器中，一共有三个线程在工作。
 
上面我们已经大概了解的什么是复制？为什么要复制？如何复制？这三个问题了，接下来我们基于上面的介绍，提出一些实际应用可能会发生的问题来思考如何解决。博主自问自答的方式-。-
 
问答环节
 
问题一：通过复制模型虽然读能力可以通过扩展slave机器来达到提高，而写能力却不能，如果写达到瓶颈我们应该怎么做呢？
 
答：我们首先会得出结论，这种复制模型对于写少读多型应用是非常有优势的，其次，当遇到这种问题的时候我们可以对数据库进行分库操作，所谓分库，就是将业务相关性比较大的表放在同一个数据库中，例如之前数据库有A，B，C，D四张表，A表和B表关系比较大，而C表和D表关系比较大，这样我们把C表和D表分离出去成为一个单独的数据库，通过这种方式，我们可以将原有的单点写变成双点写或多点些，从而降低原有主库的写负载。
 
问题二：因为复制是有延迟的，肯定会发生主库写了，但是从库还没有读到的情况，遇到这种问题怎么办？
 
答：MySQL支持不同的复制策略，基于不同的复制策略达到的效果也是不一样的，如果是异步复制，MySQL不能保证从库立马能够读到主库实时写入的数据，这个时候我们要权衡选择不同复制策略的利弊来进行取舍。所谓利弊，就是我们是否对从库的读有那么高的实时性要求，如果真的有，我们可以考虑使用同步复制策略，但是这种策略相比于异步复制策略会大大降低主库的响应时间和性能。我们是否可以在应用的设计层面去避开这个问题？
 
问题三：复制的不同模式有什么优缺点？我们如何选择？
 
答：基于语句的复制实际上是把主库上执行的SQL在从库上重新执行一遍，这么做的好处是实现起来简单，当前也有缺点，比如我们SQL里面使用了NOW()，当同一条SQL在从库中执行的时候显然和在主库中执行的结果是不一样的，注入此类问题可以类推。其次问题就是这种复制必须是串行的，为了保证串行执行，就需要更多的锁。
 
基于行的复制的时候二进制日志中记录的实际上是数据本身，这样从库可以得到正确的数据，这种方式缺点很明显，数据必须要存储在二进制日志文件中，这无疑增加的二进制日志文件的大小，同时增加的IO线程的负载和网络带宽消耗。而相比于基于语句的复制还有一个优点就是基于行的复制无需重放查询，省去了很多性能消耗。
 
无论哪种复制模式都不是完美的，日志如何选择，这个问题可以在理解他们的优缺点之后进行权衡。
 
问题四：复制的工作过程只有三个线程来完成，对于Master来说，写是并发的，也就出现了一个IO线程要把所有并发的数据变更事件记录，这个IO线程会不会累死？当一个Master对应多个Slave的时候，其实在Master中会唤起多个IO线程，这无疑会增加Master的资源开销，如果出现事件堆积，也就是事件太多，来不及及时发送出去怎么办？另外就是Slave那边的IO线程和SQL线程也会有对应主库并发数据变更事件，而Slave方单个线程处理的问题，这个时候Slave线程会不会累死？
 
答：上面的问题确实会发生，上面第一个问题和第二个问题其实是写负载的问题，当事件堆积太多，从库时延就会变大，Slave单SQL线程问题据说有参数可以开启并行操作，这个大家可以确认一下。
 
问题五：针对复制工作过程可能会出现的问题，主库写完二进制日志文件同时都会保存二进制日志的偏移量，但是当断电的时候，二进制日志文件没有刷新到磁盘，主库重新启动之后，从库尝试读该偏移量的二进制日志，会出现读不到的情况，这个问题应该怎么解决？
 
答：首先如果开启了sync_binlog选项，对于innodb同时设置innodb_flush_log_at_trx_commot=1，则可以保证二进制日志文件会被写入磁盘，但MyISAM引擎可能会导致数据损坏。如果没有开启这个选项，则可以通过制定从库的二进制偏移量为下一个二进制日志文件的开头，但是不能解决事件丢失问题。
 
问题六：从库在非计划的关闭或重启时，回去读master.info文件去找上次停止复制的位置，这同样会有一个问题，如果master.info不正确，就会导致复制数据不一致的情况，遇到这个问题怎么办？
 
答：这个问题可以通过两种方式解决，一是控制master.info在从库非计划关闭或重启的时候让master.info能够同步到磁盘，这样下次启动的时候就不会读取错误的信息，这有助于减少错误的发生概率。另外想要找到正确的复制位置是困难的，我们也可以选择忽略错误。
 

 
请点击输入图片描述
 
请点击输入图片描述

 
AE合成复制机插件(AE快速复制脚本)是一款很优秀好用的AE上的快速复制辅助工具。小编带来的这款AE合成复制机插件功能强大全面，简单易用，使用后可以帮助用户更轻松便捷的在AE中进行快速复制操作，非常方便实用。使用脚本能够复制出所选comp的完整副本，包括带有许多选项的子合成。如果一个comp被多次使用，则该comp仅被复制一次，并且所有其余引用都指向第一个重复。有需要的朋友欢迎来下载使用。
 
安装说明：
 
01、复制脚本True Comp Duplicator.jsx文件到
 
– (Windows) Program Files\Adobe\Adobe After Effects \Support Files\Scripts\ScriptUI Panels
 
– (Mac OS) Applications(应用程序)/Adobe After Effects \Scripts\ScriptUI Panels
 
02、在After Effects中, 菜单 Window(窗口) > True Comp Duplicator.jsx
 
操作说明：
 
运行脚本后下图第一项指的是：在要复制的合成名字前/后增加序号，第二项指的是要不要新创建一个文件夹，并命名，下面的副本数量是要把合成复制几个。其他参数根据自己需要来选择。完成后点确定即可。
 

 
MySQL复制格式
 
1.基于语句复制的优势:
 
属于比较成熟的技术，得到广泛使用 当SQL语句会修改很多数据时，使用语句复制会比较节省空间 由于二进制文件中包含了所有的修改语句，所以可以用来做审计功能
 
2.基于语句复制的劣势: 某些特定的修改语句在基于语句复制的环境中复制会有问题，比如: 语句中包含自定义函数或者不确定性的存储过程 update/delete语句中包含Limit语句但不包含order by语句属于不确定性语句 一些函数比如rand(), sysdate()，version()等由于不确定性也会导致复制异常 每个导致复制异常的语句都会产生一个告警信息
 
[Warning] Statement is not safe to log in statement format.
 
3.基于行复制的优势:
 
所有的数据库修改都可以被复制，是一种安全的方式 由于是行复制，所以某些语句在主库和从库上执行需要较少的lockd,当DML语句涉及到多行的修改时，则由于行复制会把每行的修改信息都记录下来，所以 bin log会很大，有可能会导致复制的延迟相比较语句复制要大不能直接查看在备库中执行的SQL语句建议仅使用InnoDB表做行复制，对MyISAM表的行复制有可能会导致复制异常;
 
基于语句复制的二进制文件内容:
 
log-bin=mysql-bin
 
server_id=1
 
binlog-format=statement
 
基于行复制的二进制文件内容:
 
log-bin=mysql-bin
 
server_id=1
 
binlog-format=row
 
执行命令:bin/mysqlbinlog -v data/mysql-bin.000003
 
假如主库的temp表数据展示如下:
 
mysql> select * from temp;
 
+------+------+
 
| id | name |
 
+------+------+
 
| 2|eee|
 
| 3|eee|
 
| 4|eee|
 
| 5|eee|
 
备库的temp数据展示如下:
 
mysql> select * from temp;
 
+------+------+
 
| id | name |
 
+------+------+
 
| 3|eee|
 
| 2|eee|
 
| 4|eee|
 
| 5|eee|
 
+------+------+
 
主库执行delete from temp limit 1;
 
则主库删掉的数据是id=2的行，而备库删掉的是id=3的行。导致主备库数据不一致
 
在statement环境下实验主从一个表数据不一致的情况下复制是否还能继续:
 
mysql> show variables like '%format%';
 
+---------------------------+-------------------+
 
| Variable_name | Value |
 
+---------------------------+-------------------+
 
| binlog_format | STATEMENT |
 
从库执行:
 
mysql> delete from temp where id<10000;
 
主库执行:
 
mysql> delete from temp where id=1;
 
查看从库的同步状态依然正常:
 
mysql> show slave status\G
 
*************************** 1. row ***************************
 
Slave_IO_Running: Yes Slave_SQL_Running: Yes
 
Last_Errno: 0
 
Last_Error:
 
Seconds_Behind_Master: 0
 
在行复制环境下实验主从一个表数据不一致的情况下复制是否还能继续:
 
mysql> show variables like '%format%';
 
+---------------------------+-------------------+
 
| Variable_name | Value |
 
+---------------------------+-------------------+
 
| binlog_format | ROW|
 
主库执行:
 
mysql> delete from temp where id=2;
 
查看从库的同步状态不正常:
 
mysql> show slave status\G
 
*************************** 1. row ***************************
 
Slave_IO_Running: Yes
 
Slave_SQL_Running: No
 
Replicate_Do_DB: test
 
Last_Errno: 1032
 
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The
 
most recent failure being: Worker 4 failed executing transaction 'ANONYMOUS' at master log mysql-bin.000002, end_log_pos 386. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
 
如果手工在备库增加这条数据，则同步再次正常:
 
Insert into temp values(2,'mike');
 
mysql> show slave status\G
 
*************************** 1. row ***************************
 
Slave_IO_Running: Yes Slave_SQL_Running: Yes
 
Last_Errno: 0
 
Last_Error: Skip_Counter: 0
 
Seconds_Behind_Master: 0
 
MySQL复制涉及三个线程，其中一个在主库，另两个在从库binlog dump thread:在主库创建，用来在从库链接过来时发送bin log的内容slave io thread:在备库创建，用来连接主库并请求发送新的bin log内容。
 
该线程读取主库的bin log dump线程发送的更新内容并将此内容复制到本地的relay log中Slave sql thread:在备库创建，读取slave io线程在本地relay log中的内容并在本地执行内容中的事件
 
MySQL复制使用场景
 
MySQL复制可以作为数据库备份的一种解决方案，由于主库的数据会复制到备库，所以可以在备库执行数据库备份作业而不用影响主库的性能在备库的备份通常有两种选择: 当数据库比较小时，可以采用mysqldump的方式。由于mysqldump出来的文件内容是SQL语句，所以可以很方便的将其中的一部分复制出来应用到其他数据库里。在执行mysqldump之前，为了保证数据的一致性，最好是把slave进程停掉。
 
mysqladmin stop-slave或者mysql -e 'STOP SLAVE SQL_THREAD;'
 
mysqldump --all-databases > fulldb.dump
 
mysqladmin start-slave
 
当数据库比较大时，采用mysqldump方式的效率不高，所以可以使用物理文件拷贝的方式。为了保证数据的一致性，物理备份需要将备库关闭
 
shell> mysqladmin shutdown
 
shell> tar cf /tmp/dbbackup.tar ./data
 
/etc/init.d/mysql.server start
 
MySQL复制可以用在主库和从库采用不同的存储引擎的情况下。这样做的目的通常是在主库和从库可以分别利用不同存储引擎的优势，比如在主库使用 InnoDB是为了事务功能，而从库使用MyISAM因为是只读操作而不需要事务功能
 
当使用mysqldump方式来创建备库时，改变备库的表存储引擎的方式就是在 应用dump文件之前先修改文件里的所有关于表存储引擎的地方
 
如果是使用文件拷贝的方式来创建备库时，则唯一修改备库表存储引擎的方式 就是在启动备库之后使用alter table命令修改
 
mysql> STOP SLAVE;
 
mysql> alter table temp engine='myisam';
 
mysql> START SLAVE;
 
MySQL复制可以用来做负载均衡功能的水平扩展，最主要是将数据库的读压力分担到多个MySQL slave实例上，这种情况适用在读多写少的环境中。比如 一个基本的WEB架构:
 
MySQL复制可以用在当需要将主库上的不同数据库复制到不同的slave上，以便在不同的slave上执行不同的数据分析任务时。可以在每个slave上配置不同的参数来约束复制过来的数据，通过replicate-wild-do-table参数或者replicate-do-db参数
 
slave1上应该配置参数replicate-wild-do-table=databaseA.% slave2上应该配置参数replicate-wild-do-table=databaseB.% slave3上应该配置参数replicate-wild-do-table=databaseC.%每个slave其实是接收到完整的bin log日志，但在应用环节中会进行过滤，仅应用符合参数配置的事件在配置完参数之后，通过mysqldump的方式将对应数据库在slave应用起来，再启动slave线程
 
MySQL延迟复制
 
延迟复制是指定从库对主库的延迟至少是指定的这个间隔时间，默认是0秒。可以通过change master to命令来指定
 
CHANGE MASTER TO MASTER_DELAY = N;
 
其原理是从库收到主库的bin log之后，不是立即执行，而是等待指定的秒数之后再执行
 
延迟复制的使用场景比如:
 
确保在主库上被错误修改的数据能及时找回
 
测试在从库IO集中在恢复bin log过程中对应用程序的访问影响保留一份若干天前的数据库状态，和当前状态可以做对比 show slave status中SQL_Delay值表明了设置的延迟时长
 
MySQL复制主从切换
 
如果是使用GTID的复制方式，可以使用mysqlfailover工具做主从复制状态的监控和自动切换;如果是使用非GTID模式，则需要使用其他的方式做监控和切换
 
当新的master产生之后，需要通过在其他slave上执行change master to语句来对应到新的master上。slave不会检查自己的数据库和新的master上是否一致，而是直接获取master上的二进制日志并继续自己的复制功能新当选master的实例需要运行在log_bin模式下新的master上开启
 
log-bin=mysql-bin
 
Master上查看bin log信息
 
mysql> show master status;
 
在slave上执行:
 
mysql> reset slave all;
 
Query OK, 0 rows affected (0.01 sec)
 
mysql> stop slave;
 
mysql> CHANGE MASTER TO
 
-> MASTER_HOST='192.168.237.130',
 
-> MASTER_PORT=3308,
 
-> MASTER_USER='repl',
 
-> MASTER_PASSWORD='mysql',
 
-> MASTER_LOG_FILE='mysql-bin.000001',
 
-> MASTER_LOG_POS=154;
 
mysql> start slave;
 
MySQL半同步复制
 
默认创建的MySQL复制是异步的，意味着主库将数据库修改事件写入到自己的bin log，而并不知道从库是否获取了这些事件并应用在自己身上。所以当主 库崩溃导致要主从切换时，有可能从库上的数据不是最新的
 
从5.7版本开始MySQL通过扩展的方式支持了半同步复制
 
当主库执行一个更新操作事务时，提交操作会被阻止直到至少有一个半同步的复制slave确认已经接收到本次更新操作，主库的提交操作才会继续半同步复制的slave发送确认消息只会在本次更新操作记录已经记录到本地的 relay log之后如果没有任何slave发送确认消息而导致超时时，半同步复制会转换成异步复制
 
半同步复制会对MySQL性能产生影响，因为主库的提交动作只有在收到至少 一个从库的确认消息之后才能执行。但这个功能是性能和数据可靠性方面的权 衡
 
MySQL半同步复制
 
rpl_semi_sync_master_wait_point参数用来控制半同步复制的行为: AFTER_SYNC:默认值
 
AFTER_COMMIT
 
需要配置的系统参数包括:
 
rpl_semi_sync_master_enabled:在主库配置，确保主库的半同步复制功能 开启
 
rpl_semi_sync_master_timeout:配置主库等待多少毫秒时间来保证接收备 库的确认消息，当超过这个时间时，半同步变成异步方式 rpl_semi_sync_slave_enabled:在从库配置，确保从库的半同步复制功能开启
 
半同步复制是通过插件的方式建立，要分别在主库和从库安装一个插件前提条件:
 
5.5版本及以上 have_dynamic_loading参数必须是YES代表可以安装插件并动态加载事先建立好异步复制关系
 
相关的插件安装文件会在plugin_dir文件夹下，并以semisync_master和semisync_slave名字打头
 
主库上安装插件:
 
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 在每个从库上安装插件:
 
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; 查看插件的安装情况:
 
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
 
FROM INFORMATION_SCHEMA.PLUGINS
 
WHERE PLUGIN_NAME LIKE '%semi%';
 
+----------------------+---------------+
 
| PLUGIN_NAME | PLUGIN_STATUS |
 
+----------------------+---------------+
 
| rpl_semi_sync_master | ACTIVE |
 
+———————————+---------------+
 
在主库上开启半同步复制:
 
SET GLOBAL rpl_semi_sync_master_enabled = 1;
 
SET GLOBAL rpl_semi_sync_master_timeout = N; ##N是毫秒，默认是10000，代表10秒 在备库上开启半同步复制:
 
SET GLOBAL rpl_semi_sync_slave_enabled =1;
 
在备库上重启slave进程:
 
STOP SLAVE IO_THREAD;
 
START SLAVE IO_THREAD;
 
MySQL半同步复制
 
半同步复制监控参数:
 
Rpl_semi_sync_master_clients:检查半同步的slave个数
 
Rpl_semi_sync_master_status:1表示主库的半同步功能开启并且运行正常 ，0表示主库的半同步功能关闭或者半同步复制已经变成了异步复制
 
Rpl_semi_sync_master_no_tx:表示有多少提交没有收到slave的确认消息
 
Rpl_semi_sync_master_yes_tx:表示有多少个提交收到了slave的确认消息
 
Rpl_semi_sync_slave_status:1表示备库上slave功能开启并且运行正常，0 表示功能为开启或者运行异常
 
通过命令mysql> SHOW STATUS LIKE 'Rpl_semi_sync%';查看各个参数的状态
 
MySQL半同步复制
 
从库关闭IO线程
 
mysql> STOP SLAVE IO_THREAD;
 
Query OK, 0 rows affected (0.00 sec)
 
主库执行update数据操作，需要等待10秒才能返回
 
mysql> update temp2 set name='ddd' where id=12;
 
超时返回之后，从库的半同步状态变成OFF状态
 
mysql> show status like '%Rpl_semi%';
 
| Rpl_semi_sync_slave_status | OFF |
 
当从库同步正常后，半同步状态显示正常
 
mysql> START SLAVE IO_THREAD;
 
Query OK, 0 rows affected (0.00 sec)
 
mysql> show status like '%Rpl_semi%';
 
| Rpl_semi_sync_slave_status | ON |
 
当有两个从库都开启半同步复制时，停止其中一个的slave IO线程，再在主库上执行插入，操作很快返回
 
mysql> insert into temp2 values(131,'a');
 
Query OK, 1 row affected (0.00 sec)
 
当把第二个从库的slave IO线程关闭时，则主库插入数据需要等待10秒才能返回
 
mysql> insert into temp2 values(132,‘a’); ##等待10秒
 
MySQL基于GTID的复制
 
GTID(global transaction identifiers)复制是完全基于事务的复制,即每个在主库上执 行的事务都会被分配一个唯一的全局ID并记录和应用在从库上 这种复制方式简化了建立slave和master/slave之间切换的工作，因为其完全不需要找当前执行的bin log和log中的位置完成切换 一个GTID是master上执行的任何commit事务所分配的全局唯一ID标示，
 
其由两部分组成
 
GTID = source_id:transaction_id Source_id代表主库的server_uuid，transaction_id代表事务按顺序提交的ID，比如第 一个提交则是1，第十个提交的事务就是10
 
GTID集合代表一组GTID
 
1.当一个事务在主库提交时，该事务就被赋予了一个GTID，并记录在主库的binary log
 
2.主库的binary log会被传输到从库的relay log中，从库读取此GTID并生成gtid_next系统参数
 
3.从库验证此GTID并没有在自己的binary log中使用，则应用此事务在从库上MySQL5.6的GTID复制模式，slave必须开启bin-log和log_slave_updates参数，否则启动就报错，因为需要在binlog找到同步复制的信息(UUID:事务号) (注:开启log_slave_updates参数，是把relay-log里的日志内容再记录到slave本地的 binlog里。)
 
但在MySQL5.7里，官方做了调整，用一张gtid_executed系统表记录同步复制的信息 (UUID:事务号)，这样就可以不用开启log_slave_updates参数，减少了从库的压力
 
从MySQL5.7.4版本开始，GTID会存放在mysql系统库的gtid_executed表中
 
CREATE TABLE gtid_executed ( source_uuid CHAR(36) NOT NULL,
 
interval_start BIGINT(20) NOT NULL,
 
interval_end BIGINT(20) NOT NULL,
 
PRIMARY KEY (source_uuid, interval_start) )
 
show master status;
 
select * from mysql.gtid_executed;
 
MySQL基于GTID的复制
 
创建复制流程 假定两个数据库实例间的主从关系已经通过传统模式创建好了
 
将主库和从库都设置为read only，确保两者之间的数据都完全同步
 
mysql> SET @@global.read_only = ON;
 
关闭主库和从库
 
mysqladmin -uusername -p shutdown
 
设置主从库GTID后启动并暂时关闭slave进程
 
[mysqld]
 
gtid-mode=on
 
enforce-gtid-consistency=on
 
skip-slave-start=1
 
#Enforce-gtid-consistency参数是确保只有对gtid复制机制安全的语句才会被log
 
重新设置主从库的复制关系
 
mysql> CHANGE MASTER TO
 
MASTER_HOST = host,
 
MASTER_PORT = port,
 
MASTER_USER = user,
 
MASTER_PASSWORD = password,
 
MASTER_AUTO_POSITION = 1;
 
启动slave进程
 
mysql> START SLAVE;
 
关闭主库的read only模式
 
mysql> SET @@global.read_only = OFF;
 
使用GTID复制的限制条件:
 
由于GTID复制是依赖于事务的，所以MySQL的一些属性不支持当一个事务中既包含对InnoDB表的操作，也包含对非事务型存储引擎表 (MyISAM)的操作时，就会导致一个事务中可能会产生多个GTID的情况;或者是当master和slave的表使用的存储引擎不一样时，都会导致GTID复制功能不正常
 
create table...select语句在基于语句复制的环境中是不安全的，在基于行复制的环境中，此语句会被拆分成两个事件，一是创建表，二是insert数据，在某 些情况下这两个事件会被分配相同的GTID，而导致insert数据的操作被忽略， 所以GTID复制不支持create table ... select语句
 
create/drop temporary table语句在GTID复制环境中不能放在事务中执行,只能单独执行，并且autocommit要开启 sql_slave_skip_counter语句是不支持的，如果想要跳过事务，可以使用 gtid_executed变量
 
mysql> create table temp2 select * from temp;
 
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT.
 
mysql> create table temp2(id int,name varchar(10)) engine=myisam;
 
Query OK, 0 rows affected (0.02 sec)
 
mysql> start transaction;
 
Query OK, 0 rows affected (0.00 sec)
 
mysql> insert into temp2 select * from temp;
 
Query OK, 3 rows affected (0.01 sec) Records: 3 Duplicates: 0 Warnings: 0
 
mysql> commit;
 
Query OK, 0 rows affected (0.00 sec)
 
mysql> start transaction;
 
Query OK, 0 rows affected (0.00 sec)
 
mysql> update temp set name='abc';
 
Query OK, 3 rows affected (0.02 sec)
 
Rows matched: 3 Changed: 3 Warnings: 0
 
mysql> insert into temp2 select * from temp;
 
ERROR 1785 (HY000): Statement violates GTID consistency: Updates to non- transactional tables can only be done in either autocommitted statements or single-statement transactions, and never in the same statement as updates to transactional tables.