Master/Slave

Master: write/read，写操作都在主节点上操作

Slaves: read，读操作都是从节点这边发出

为什么要复制？

冗余：promte（提升为主），异地灾备，可以通过人工或者工具程序（MHA）实现

扩展：转移一部分“读”请求；

支援安全的备份操作；

测试需要；

主/从架构实现：

在主节点上启用二进制日志，从节点启动连接线程，请求主节点把这个事件发给自己一份，从节点上有一个线程叫IO Thread,主节点上启用dump thread，IO Thread从节点将接受到的日志存储到中继日志，从服务器上的SQL THread负责从中继日志里生成一份数据。这样的数据同步方式是异步。主服务器负责写操作，从服务器负责读操作。

主从有可能导致主从数据不一致。如主服务多线程进程，从服务区是单线程进程，有可能导致主从数据不一致，从服务器的数据可能会落后于主服务器，这个问题是不可避免的，只能尽早发现，将不正确的数据手动更改，如果数据差别很大，手动恢复很难，可以在主服务器上做备份，把数据直接回复到从服务器上。

主服务器存到二进制log，存到从服务器上是异步操作的。传输是单向的。但是这里有个问题，如果写操作超出主服务器的性能，解决方法，使用双主模型

主从复制的三种形式：同步复制，异步复制，半同步复制

同步复制：

        双主模型：写操作都在本地写，同步给另一个节点，放到relay中。

主服务器都要启动中继日志和二进制日志，所有发给本节点的写操作，都要记录到二进制日志中，并通过dump thread发给对端主服务器，对端主服务器通过io thread将收到的数据存储到中继日志中，并依靠sql thread实现重放。主节点实现了冗余。每个节点都可以读和写操作。这种操作可以降低读请求，每个服务器负载一半的请求，但是写操作的请求数量是一样的，因为，双主的服务器都要写入一份数据。

利用中间件的读写分离器实现请求读写分离，中间件可以利用keepalive实现冗余。但是有了双主模型，就不需要读写分离，只需要用haproxy或者nginx或者lvs来实现请求的四层调度将请求调度到不同服务器上即可。

mysql主从复制弊端可能运行一段时间后，根据业务逻辑的不一样，可能导致主从数据不一致，导致得到的数据不一致。该情况在数据要求强一致的情况下是不允许存在的。

在主服务器上，操作是多线程并行的，但是记录到二进制文件中是串行记录，从服务器是单线程运行获取数据，这样导致从服务器拉取数据的速度落后于主服务器，导致了数据的差异，长此以往会导致数据严重不一致。如果这里设置读写分离，可能导致从服务器上读出的数据是错误的。双主模型同样有这个问题。主从数据不一致，建议解决办法是手动修改数据。如果数据差别太大，将从服务器关闭，在主服务器上做备份，恢复到从服务器上。

异步复制：

一主多从；

一从一主；

级联复制；一主复制给一从，同时，这个从服务器又是其他服务器的主，其他从服务器到这个中继服务器复制数据，级联的作用是降低主服务器的压力。中间的这个从服务器要启用二进制日志和中继日志，同时，中间这台从服务器仅起到过渡的作用，不需要保存数据，因此将block hole引擎用于这个中间从服务器上，使得不会产生数据保存，但是中继日志和二进制日志都有正常保存，起到过渡的效果。

循环复制；多主模式下，采用循环复制，但是链条更长，可能导致数据落后严重。

双主复制；

半同步复制：

一从多主模型：每个主服务器提供不同的数据库，master只保证slaves中的一个操作成功，就返回，其他slave不管。这个功能，是由google为MYSQL引入的。