1.复制模式
（1）MySQL 复制模式默认是异步的。主库将事务Binlog事件写入到Binlog文件中，此时主库只会通知Dump线程发送这些新的Binlog，然后主库就会继续处理提交操作，而此时不会保证这些Binlog传到任何一个从库上。
（2）半同步复制必须是主库和从库两端都开启时才可以。
（3）从库节点只有在接收到某一事务的所有Binlog,将其写入并Flush 到 Relay Log 文件之后，才会通知对应主库上的等待线程。在等待过程中，如果所有的从节点都超过了配置的超时时间，主库会自动转换为异步复制，当至少一个半同步的从节点赶上来时，主库会自动转换为半同步方式的复制。
（4）全同步复制，当主库提交事务之后，所有的从库节点必须都收到、Apply并且提交这些事务，然后主库线程才能继续做后续操作。
2.Binlog 与 Redo log的区别
（1）binlog是MySQL Server层记录的日志， redo log是InnoDB存储引擎层的日志。
（2）MySQL的binlog是逻辑日志，其记录是对应的SQL语句。而innodb存储引擎层面的重做日志是物理日志。
（3）binlog不是循环使用，在写满或者重启之后，会生成新的binlog文件，redo log是循环使用。
（4）在两阶段提交中所处的位置、功能不同。MySQL（开启Binlog）内部会自动将普通事务当作一个XA事务来处理，在提交事务的过程中，MySQL会自动为每个事务分配一个唯一的XID，这个XID会被记录到Binlog 和 InnoDB Redo log中。Prepare阶段:告诉InnoDB引擎做Prepare，InnoDB更新事务状态，并将Redo log刷入磁盘；Commit阶段：先记录Binlog日志，然后告诉InnoDB引擎做Commit。
3.两阶段提交与宕机重启对事务的处理
数据库库宕机重启，事务可能出于以下四种状态：
（1）InnoDB 引擎已经提交（commit）。此时，Binlog中也一定完整地记录了该事务。所有事务是一致的，无需处理。
（2）InnoDB已完成了Prepare阶段，Binlog中已经有了该事务的Events，但是InnoDB引擎未提交。需要通知InnoDB引擎提交这些事务。
（3）InnoDB已完成了Prepare阶段，Binlog中没有该事务的Events。因为Binlog没有记录，需要通知InnoDB回滚这些事务。
（4）InnoDB还未完成Prepare阶段，Binlog中没有该事务的Events。需要通知InnoDB回滚这些事务。
4.事务的提交过程
此时SQL已经成功执行了，已经产生了语句的redo和undo内存日志，已经进入了事务commit步骤。事务提交的整个过程如下：
5.MHA在线自动切换【Scheduled(Online) Master Switch】
Program flows for the scheduled master switch is slightly different from the master failover. For example, you do not need to power off the master server, but you need to make sure that write queries are not executed on the master. By settingmaster_ip_online_change_script, you can control how to disallow write traffics on the current master (i.e. dropping writable users, setting read_only=1, etc) before executing FLUSH TABLES WITH READ LOCK, and how to allow write traffics on the new master.
迁移命令如下/usr/local/bin/masterha_master_switch --conf=/etc/app1.cnf --master_state=alive --orig_master_is_new_slave --running_updates_limit=1000 --interactive=0
主要参数
| 参数 | 作用 |
| --master_state | 强制参数. 可选有： "dead" or "alive". 如果设置为 alive，将执行 在线切主操作。 |
| --orig_master_is_new_slave | After master switch completes, the previous master will run as a slave of the new master. By default, it's disabled (the previous master will not join new replication environments). If you use this option, you need to set repl_password parameter in the config file because current master does not know the replication password for the new master. 将老主切换成新主的slave节点。如果不指定这个参数，老主将不加入新的集群环境。 |
| --new_master_host | 可选参数。指定新的主节点。如果不指定，程序自动选举。 |
| --running_updates_limit | 单位为seconds。默认值为1 second。当老主当前写操作执行超过N秒，或者任何一台slave的 slaves behind master 超过N秒，切换都将终止。 |
| --interactive | 1为交互模式，默认；0为非交互。 |
| --skip_lock_all_tables |
可选参数。When doing master switch, MHA runs FLUSH TABLES WITH READ LOCK on a orig master to make sure updates are really stopped. But FLUSH TABLES WITH READ LOCK is very expensive and if you can make sure that no updates are coming to the orig master (by killing all clients at master_ip_online_change_script etc), you may want to avoid to lock tables by using this argument，切换过程中，老主将被施加 FLUSH TABLES WITH READ LOCK ，这是个昂贵的操作，如果你可以确定没有写操作，可以指定这个参数。 |
| --remove_orig_master_conf |
可选参数。When this option is set, if master switch succeeds correctly, MHA Manager automatically removes the section of the dead master from the configuration file. By default, the configuration file is not modified at all. |
6.MHA Scheduled(Online) Master Switch的限制条件
Online master switch starts only when all of the following conditions are met.
- IO threads on all slaves are running
- SQL threads on all slaves are running
- Seconds_Behind_Master on all slaves are less or equal than --running_updates_limit seconds
- On master, none of update queries take more than --running_updates_limit seconds in the show processlist output
The reasons of these restrictions are for safety reasons, and to switch to the new master as quickly as possible.
参考学习
1.https://blog.csdn.net/wanbin6470398/article/details/81941586
2.https://www.jianshu.com/p/65eb0526bfc0
3.MHA之masterha_master_switch
https://blog.csdn.net/xxj123go/article/details/72828920