复制
- 复制工作原理
- 快照+复制的备份架构
复制工作原理
复制（replication）是MySQL数据库提供的一种高可用高性能的解决方案，一般用来建立大型的应用
总体来说，replication的工作原理分为以下3个步骤：
- 主服务器（master）把数据更改记录到二进制日志（binlog）中
- 从服务器（slave）把主服务器的二进制日志复制到自己的中继日志（relay log）中
- 从服务器重做中继日志中的日志，把更改应用到自己的数据库上，以达到数据的最终一致性
复制的工作原理并不复杂，其实就是一个完全备份加上二进制日志备份的还原
不同的是这个二进制日志的还原操作基本上实时在进行中
这里特别需要注意的是，复制不是完全实时地进行同步，而是异步实时
这中间存在 主从服务器之间的 执行延时，如果主服务器的压力很大，则可能导致主从服务器延时较大
从服务器有2个线程
一个是I/O线程，负责读取主服务器的二进制日志，并将其保存为中继日志
另一个是SQL线程，复制执行中继日志
可以通过SHOW FULL PROCESSLIST命令查看一个从服务器的状态
在replication的主服务器上应该可以看到一个线程负责发送二进制日志
若用户要想得知当前的延迟，可以通过命令SHOW SLAVE STATUS和SHOW MASTER STATUS得知
命令SHOW SLAVE STATUS可以观察当前复制的运行状态
命令SHOW MASTER STATUS可以用来查看主服务器中二进制日志的状态
快照+复制的备份架构
复制可以用来作为备份，但功能不仅限于备份，其主要功能如下：
- 数据分布，由于MySQL数据库提供的复制并不需要很大的带宽要求，因此可以在不同的数据中心之间实现数据的复制
- 读取的负载平衡，通过建立多个从服务器，可将读取平均地分布到这些从服务器中，并且减少了主服务器的压力。一般通过DNS的Round-Robin和Linux的LVS功能都可以实现负载平衡
- 数据库备份，复制对备份很有帮助，但是从服务器不是备份，不能完全代替备份
- 高可用性和故障转移，通过复制建立的从服务器有助于故障转移，减少故障的停机时间和恢复时间
复制的设计不是简简单单用来备份的，并且只是用复制来进行备份是远远不够的
假设当前应用采用了主从的复制架构，从服务器作为备份。这时，一个初级DBA执行了误操作，如DROP DATABASE或DROP TABLE，这时从服务器也跟着运行了。这时用户怎样从服务器进行恢复呢？
因此，一个比较好的方法是 通过 对从服务器上的数据库 所在分区 做快照，以此来避免 误操作 对复制造成影响
当 发生 主服务器上的误操作时，只需要将 从服务器上的快照 进行恢复，然后 再根据 二进制日志 进行point-in-time的恢复即可
还有一些其他的方法来调整复制，比如采用延时复制，即间歇性地开启从服务器上的同步，保证大约一小时的延时
这的确也是一个方法，只是数据库在高峰和非高峰期间每小时产生的二进制日志量是不同的，用户很难精准地控制。另外，这种方法也不能完全起到对误操作的防范作用
此外，建议在从服务上启用read-only选项，这样能保证从服务器上的数据仅与主服务器进行同步，避免其他线程修改数据
在启用read-only选项后，如果 操作 从服务器 的 用户 没有SUPER权限，则对 从服务器 进行任何的修改操作 会抛出一个错误，如下所示：
mysql>INSERT INTO z SELECT 2;
ERROR 1290(HY000):The MySQL server is running with the--read-only option so it cannot execute this statement
