复制管理
监控
SHOW MASTER LOGS;
查看主库当前有哪些二级制日志，其logname是其他命令的入参， file_size是偏移量也是入参。
假设我们知道日志的偏移量(来源于上面的命令)使用：
SHOW BINLOG EVENTS IN ‘mysql-bin.0000023’ FROM 13634;
能查看最后执行的sql语句。
测量备库延迟
SHOW SLAVE STATUS命令，但是会有问题：
- 使用服务器当前日期，与二进制文件中的时间时间戳进行对别的
- 大事件会导致延迟波动
更好的解决办法是使用heart record.这是一个主库上会每秒更新一次的时间戳。
确认主备是否一致
pt-table-checksum检查主备是否一致的工具
从主库重新同步备库
移除备库，重新同步一个出来
使用mysqldump命令。 这个命令需要锁住表之后再操作
pt-table-sync工具
改变主库
计划内
- 停止写入 read only
- 停止客户端写入
- 等待备库赶上主库
- 将备库配置为主库
- 给新主库配置备库
- 向新主库开放访问权限
计划外
这种会面临，主库数据丢失， 不同步。 备库间也不同步
- 首先要确定使用那台备库，使用最新的。 SHOW SLAVE STATUS 看 Master_Log_File的值
- 让备库完成中继日志
- 导出主库的bin-log。建立空主库运行
- 使用SHOW MASTER STATUS查看日志位移
- 备库连接到临时主库继续执行位移的日志
- 提升备库为主库
复制问题
数据损坏或者丢失
主库意外宕机
如果没有设置sync_binlog，那么有一定的可能崩溃前几个二进制日志没有刷进磁盘。 重启之后备库线程再次连上来。主库会告诉他偏移量不存在。
解决方式是，让备库从下一个二进制日志的开头读，然后用工具查看主备一致性。 或者开启sync_binlog避免丢失，但是会带来性能损失
。。。 还有很多，具体的不赘述了
使用非事务型表
要保证主库重启前，运行了STOP SLAVE否则有可能数据不一致。
不确定语句
主要是基于语句的复制，这个开发的时候就要注意。考虑到有可能产生这种现象的原因。
使用唯一的服务器ID
InnoDB加锁读引起的锁争用
INSERT… SELECT操作会引起读锁，会使串行化。
可以拆分成小命令
使用SELECT INTO OUTFILE,, LOAD DATA INFILE代替INSERT..SELECT.更快，不加锁。
过大的复制延迟
注意，应用设计上要允许出现延迟
延迟一般都是突然出现的很不好监测
可以用些手段来提升备库的性能：
- 发现延迟之后如果打开了log_slows_slave_statements可以查看问题
- 关闭备库二进制日志
- 设置刷新磁盘的点innodb_flush_log_at_trx_commit
- 不重复写操作中代价较高的部分
比如一个更新统计表的操作，可以优化为。在主库中新建一个库。统计结构更新这个库。然后用SELECT INTO OUTFILE和LOAD DATA INFILE来写回主库。这样就不会再备库同步执行这个操作
基于同样的思想，还可以把这部分操作放到应用层面来做统计，然后应用层显示调用更新数据库操作。 - 在复制之外进行操作 主要是解决了备库是串行的问题
常见的有两种，一种是归档型数据库。归档操作进制归档操作记录到二进制文件中，然后在主库和备库上单独执行这些归档查询
还可以对一些特殊的表单独处理。 使用应用程序手工的方式来处理这些标的同步。这样可能会带来数据性能的提升。
主备库 包大小配置不一致
如果主备的 max_allowed_packet 不匹配，有可能主库传来过大的包。 可能造成报错或者日志损坏等等。
带宽不足
可以通过开启备库的 slave_compressed_protocol选项，来让传输时对数据进行压缩及解压。
复制速度
测试：
INSERT INTO lag_test(now_usec) VALUES (NOW_USEC())
//要保证主从库时间同步
// 注意库必须是varchar列，因为时间列的精确度可能是到秒然后使用TIMESTAMPDIFF方法来查询时间差异
可以插入1000比输入，然后根据数量级进行分组，或者求下平均值。看下一般的延迟是多久
一般情况下都是在0.几毫秒以内
一些高级特性
- 5.1引入了行复制
- 5.5引入了半同步。
在提交食物后，返回给客户端结果前保证二进制日志传输到了至少一台备库上，这样就能更好的保证主从同步。但是会给客户端事务提交的时间延迟一点点。半同步还会有一点点性能改善，因为有半同步，可以更大胆的关闭bin-log。本地写磁盘转化为远程写内存。事实证明远程写内存更快。 - 5.5还增加了复制心跳监测
- 5.6引入了并行复制，对部分并行处理
其他复制行为
Percona Toolkit和Percona Xtrabackup都提供了基于复制或者帮助复制的功能
Tungsten Java的开源中间件复制产品。提供了自动数据分片，并发执行，数据复制，款平台复制，多源复制等功能。 他很实用，一些优点：
- 内建一致性检查
- 插件特性
- 全局事务ID，不用再去匹配日致命和偏移量了
- 能快速的将备库提升为主库
- 异构复制 比如Mysql到PostgreSQL
- 不同版本之间
- 并行
缺点则是要学习，更复杂，效率稍低。
总结一下：
- 显著增加了Mysql的功能和可用性
- 不提供监控，配置，管理等功能，可以使用其他管局优化，比如：Percona Toolkit和XtraBackup
- 复制配置前需要用上面的工具来进行对比，确认是考虑
- 监控不会落后于主库
- 应用设计要避免主备延迟的脏数据情况
- 备库制度并且增加权限，不要多处写。