MySQL支持单向，异步复制，复制过程中一个服务器充当主服务器，而一个或多个其他服务器充当从服务器。
1，复制的基本原理
在主库的二进制日志里记录了对数据库的变更，从库从主库那里获取日志，然后在从库中重放这部分日志，从而实现数据的同步。
主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。
从库复制主库的二进制日志事件到本地的中继日志。
从库重放中继日志。
将从服务器设置为复制主服务器的数据后，它将连接主服务器并等待更新过程。如果主服务器失败，或者从服务器与主服务器之间失去了连接，那么从服务器将保持定期尝试连接，直到它能够继续侦听更新为止。
MySQL使用3个线程来执行复制功能，其中1个在主服务器上，另外两个在从服务器上。当从服务器发出START SLAVE命令时，从服务器将创建一个I/O线程，以连接主服务器并让它发送记录在其二进制日志中的语句。主服务器可创建一个线程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上SHOW PROCESSLIST输出中的Binlog Dump线程。从服务器I/O线程读取主服务器Binglog Dump线程发送的内容并将该数据复制到从服务器数据目录中的本地文件中，即中继日志。第3个线程是SQL线程，由从服务器创建，用于读取中继日志并执行日志中所包含的更新。
这样读取和执行语句将被分成两个独立的任务，每个从服务器都有自己的I/O和SQL线程，即使SQL线程执行得很慢，远远落后于主库，但I/O线程仍然可以从主库上获取所有二进制日志的内容，这样就可以允许主库清空二进制日志了，因为不再需要等待从库来读取二进制日志的内容。
2，复制的用途
跨IDC备份数据
使用读写分离架构扩展读
在从库上进行备份
使用从库测试数据库版本升级
高可用自动故障冗余切换
错误保护（主服务器进行了错误的操作，如果从库有延迟，那么还可以从从库中恢复）
延迟服务器（测试延迟对业务的影响，最大多大延迟会影响到业务）
3，注意事项
1，复制架构中的从库一般用于扩展读，对于扩展写没有什么用处，复制对于频繁读和少量写的系统好处最大。
2。从库配置为只读，因为应用程序可能会配置错误，对从库进行写操作，将会导致数据的不一致性，甚至丢失数据。
3，互为主从的环境，一定要保证同一时刻只写一个数据库。
4，二进制日志
记录更改数据的所有语句，还用于复制。二进制日志包含了所有更新了数据或已经潜在更新了数据的语句。语句以事件（event）的形式保存，它描述了数据的更改信息。二进制日志还包含了每个更新数据库的语句的执行时间信息，但它不宝航没有修改任何数据的语句。二进制日志的主要目的是恢复数据，因为二进制日志包含备份后进行的所有的更新。
默认情况下，并不是每次写入的二进制日志都会与磁盘同步，因此如果操作系统或机器发生崩溃，那么二进制日志中最后的语句很有又能就会丢失，想要防止这种情况的发生，可以设置sync_binlog全局变量为N（1是最安全的值，但也是最慢的），使二进制日志在每N次二进制日志写入后就与硬盘同步一次。
设置过期策略，expire-logs-days=10，该语句的意思是设置过期日期为10天，expi-logs-days的设置会早运行flush logs命令后出发删除过期的日志，不要使用rm命令手动删除日志，这可能会导致你执行日志清理命令失败。
5，主从延时
从show slave status中可以看到Seconds_Behind_Master，这是从库落后多少的一个指标。一般是基于同一集群内网的主从集群，此值应为0，本字段用于测量从库SQL线程和从库I/O线程之间的时间差距，单位为秒。
如果主服务器和从库之间的网络连接比较快，则从库的I/O线程会非常接近主服务器，所以本字段能够十分近似地指示从库SQL线程比主服务器落后多少。如果网络较慢，则这种指示不准确，从库SQL线程经常能追上读取速度较慢的从库I/O线程，因此，Seconds_Behind_Master的值经常显示为0，及时从库I/O线程落后于主服务器时也是如此，换句话说，这个字段只对速度快的网络有用。
注意:这个字段输出估算具体的主从差异时间可能会不准，异常情况下Seconds_Behind_Master的值为NULL，或者显示不正常，所以生产环境的实际监控一般是在主从中配置一个心跳表，通过心跳表来监控主从之间的时间差异
通过Read_Master_Log_Pos，Exec_Master_Log_Pos，Seconds_Behind_Master这三个值来判断更加准确，如果Read_Master_Log_Pos=Exec_Master_Log_Pos并且Seconds_Behind_Master=0，那么可以认为是没有延迟的
网友评论