MySQL-复制

复制功能不仅有利于构建高性能的应用，同时也是高可用性、可扩展性、灾难恢复、备份以及数据仓储等工作的基础。

MySQL支持两种复制方式：基于行的复制和基于语句的复制。基于语句的而复制（逻辑复制）在很早的版本就支持，基于行的复制在5.1版本中被支持。

复制应用场景：
数据分布，负载均衡，备份，高可用性和故障切换，MySQL升级测试

复制步骤：
在主库上把数据更改记录到二进制日志中。
备库将主库上的日志复制到自己的中继日志中。
备库读取中级日志中的事件，将其重放到备库数据之上。

配置复制：
在每台服务器上创建复制账号。
配置主库和备库。
通知备库连接到主库并从主库渎职数据。

创建复制账号：
grant replication slave,replication client on . to repl@‘192.168.0.%’ identified by ‘****’;

配置主库和备库
在主库的my.cnf文件中增加或修改如下内容:
log_bin=mysqk_bin
server_id=10

在备库上修改my.cnf中增加类似的配置，并且通过杨需要重启服务器。
log_bin=mysql_bin
server_id=2
relay_log=/var/lib/mysql-relay-bin
og_slave_update=1
read_only=1

启动复制
change master to maste_host=‘server1’, master_suer=‘repl’, master_passward=’****’, master_log_file=‘mysql_bin.00001’, master_log_pos=0;

校验执行语句
show slave status\G

开始复制：
start slave;

查看备库向主库发起的连接：
show processlist\G

保持主库和备库同步条件：
在某个时间点的主库的数据快照；
主库当前的二进制日志文件，和获得数据快照时在该二进制日志文件中的偏移量，我们把这两个值称为日志文件坐标。通过这两个值可以确定二进制文件的位置。可以通过show master status命令来获取这些值。
从快照时间到现在的二进制日志。

从别的服务器克隆备库的方法：
使用冷备份：关闭主库，把数据复制到备库。重启主库后，会使用一个新的二进制日志文件，我们在备库通过执行change master to 指向这个文件的起始处。这个方法的缺点很明显：在复制数据时需要关闭主库。

使用热备份：如果仅使用了MYiSAM表，可以在主库运行时使用mysqlhotcopy或rsync来复制数据。
使用mysqldump:如果只包含InnoDB表，那么可以使用以下命令来转存主库数据并将其加载到备库，然后色湖之相应的二进制日志坐标：
mysqldump --single-transaction --all-databases --master-data=1 --host=server1 |mysql --host=server2

使用快照或备份：只需要知道对应的二进制日志坐标，就可以使用主库的快照或者备份来时初始化备库。只需要把备份或者快照恢复到备库，然后使用change master to指定二进制日志的坐标。

使用percona xtrabackup:percona的ctrabackup是一款开源的热备份工具，它能够在备份时不阻塞服务器的操作，因此可以在不影响主库的情况下设置备库。可以通过克隆主库或者另一个已存在的备库的方式来建立备库。

使用另外的备库：可以使用任何一种提及的克隆或者拷贝技术来从任意一台备库数据克隆到另外一台服务器。

主库上二进制日志最重要的选项：
sync_binlog=1

如果使用InnoDB，我们强烈推荐设置如下选项：
innodb_flush_logs_at_trx_commit
innodb_support_xa=1
innodbd_safe_binlog

配置二进制日志名：
log_bin=/var/lib/mysql/mysql-bin

在备库上面指定相应的配置：
relay_log=/path/to/logs/relay-bin
skip_slave_start
read_only

基于行的复制模式能够更高效地复制数据。重放一些查询的代价可能会很高。将查询的数据汇总到一张表中：
insert into summary_table(col1,col2,col3) select col1,col2,col3 from enormous_table group by col1,col2;

基于语句的复制方式代价会小很多：
update enormous_table set col1=0;

在实际中基于行的复制模式整体上更优，并且在实际中也适用于大多数场景。

基于语句的复制模式优缺点：当主备的模式不同时，逻辑复制能够在多种情况下工作。例如，在主备上的表的定义不同单数类型相兼容、列的顺序不同等情况。这样就很容易先在备库上修改schema，然后将其提升为主库，减少停机时间。基于语句的复制模式一般允许更灵活的操作。就语句的方式执行复制的过程基本上就是执行SQL语句。这意味着所有在服务器上发生的变更都以一种更容易理解的方式运行。这样当出现问题时就可以很好地定位。但在很多情况下基于语句的模式无法正确复制，几乎每一个安装的备库都至少碰到一次。事实上对于存储过程，触发器以及其他的一些语句的复制在5.0和5.1的一些列版本中存在大量的bug。这些语句的复制的方式已经被修改了很多次，以使其更好地工作。因此，如果正在使用触发器或者存储过程，就不要使用基于语句的复制模式，除非能够清楚地确定不会碰到复制问题。

基于行的复制模式的优缺点：几乎没有基于行的复制模式无法处理的场景。对于所有的SQL构造、触发器、存储过程都能正确执行。只有当你试图做一些诸如在备库修改表的schema这样的事情时才可能导致复制失败。这种方式可以减少锁的使用，因为它并不要求这种强行串行化是可重复的。但是由于语句并没有在日志里记录，因此无法判断执行了那些SQL，除了需要知道行的变化外，这在很多情况下也很重要。

复制过滤器
在主库上过滤记录到二进制日志的事件，在备库上过滤记录到中继日志的事件，通过选项binlog_do_db和binlog_ignore_db来控制过滤。

在备库上，可以通过设置replicate_*选项，在从中继日志中来读取事件时进行过滤。你可以复制或忽略一个或多个数据库，把一个数据库重写到另外一个数据库，或者使用类似like的模式复制或忽略数据库表。

复制拓扑：
一个MySQL备库实例只能有一个主库。
每个备库必须有一个唯一的服务器ID。
一个主库可以有多个备库。
如果打开了log_slave_updates选项，一个备库可以把其主库的数据变化传播到其他备库。

监控复制
在主库上使用show master status命令来查看当前主库的二进制日志位置和配置。查看当前主库有哪些二进制日志是磁盘上的:show master logs;通过show binlog events来查看复制事件。

测量备库延迟
备库seconds_behind_master值是通过将服务器当前的事件戳于二进制日志的事件的事件戳相比较得到的，所以只有在执行事件时才能报告延迟。
如果备库复制线程没有运行，就会报延迟为NULL。
一些错误可能中断复制并且停止复制线程，但second_behind_master将显示为0而不是显示错误。
即使备库线程正在运行，备库有时候无法计算延时。如果发生这种情况，备库会报0或NULL。
一个大事务可能会导致延迟波动。
如果分发主库落后了，并且其本身也有已经追赶上它的备库，备库的延迟将显示为0，而事实上和源主库之间是有延迟的。

确定主备是否一致
通常情况下可以在主库上运行该工具，参数如下：
pt-table-checksum --replicate-test.checksum <master_host>

从主库重新同步备库
使用mysqldump转储受影响的数据并重新导入，如果在繁忙的服务器上有可能行不通。可以通过复制改变备库数据，而pt-table-sync可以解决该问题。

将备库提升为主库步骤：
停止向老的主库写入。
让备库追赶上主库。
将一台备库配置为新的主库。
将备库和写操作指向新的主库，然后开启主库的写入。

大多数配置需要的步骤：
1.停止当前主库上的所有写操作。如果可以，最好能将所有的客户端程序关闭。为客户端程序建立一个“do not run"这样的类似标记可能会有所帮助。如果正在使用虚拟IP地址，也可以简单地关闭虚拟IP，然后断开所有的客户端连接以关闭其打开的事务。
2.通过flush table with read lock在主库上停止所有活跃的写入，这一步是可选的。也可以在主库上设置read_only选项。从这一刻开始，应该向即将被替换的主库做任何写入。因为一旦他不是主库，写入就意味着数据丢失。
3.选择一个备库作为新的主库，并确保它已经完全跟上主库。
4.确保新主库和旧主库的数据是一致的。
5.在新主库上执行stop slave。
6.在新主库上执行change master to master_host=’’,然后执行reset slave，使其断开于老主库的连接，并丢弃master.info里面记录的信息。
7.执行show master status记录新主库的二进制日志坐标。
8.确保其他备库已经追赶上。
9.关闭旧主库。
10.在MySQL 5.1以上版本中，如果需要，激活新主库上事件。
11.将客户端连接到新主库。
12.在每台备库上执行change master to 语句，使用之前通过how master status获得的二进制日志坐标，来指向新的主库。

计划外的提升：
确定哪台备库的数据最新。检查每台备库上show slave status命令的输出，选择其中master_log_file/read_master_log_pos的值最新的那个。
让所有备库执行完所有其他从崩溃的旧主库哪里获得的中继日志。如果在未完成前修改备库的主库，它会抛弃剩下的日志事件，从而无法获知该备库在什么地方停止。
执行前一小节的5-7步。
比较每台备库和新主库上的master_log_file/read_master_log_pos的值。
执行前一小节的10-12步。

切换服务器角色：
停止主动服务器上的所有写入。
在主动服务器上执行set global read_only=1,同时在配置文件里也设置一下read_only，防止重启后失效，但记住者不会阻止拥有超级权限的用户修改数据。如果想要阻止所有人修改数据，可以执行flush tables with read lock。如果没有这么做，你必须kill所有的客户端连接来保证没有长时间运行的语句或者提交的事务。
在主动服务器上执行show master status并记录二进制日志坐标。
使用主动服务器上的二进制日志坐标在被动服务器上执行select master_pos_wait()。该语句将阻塞住，直到复制跟上主动服务器。
在被动服务器上执行set global read_only=0，这样就变成主动服务器。
修改应用的配置，使其写入到新额主动服务器中。

复制的问题和解决方案

数据损坏或丢失的错误

主库意外关闭，备库意外关闭，主库上的二进制日志损坏（数据改变，但事件仍是有效的SQL；数据改变并且事件是无效的SQL；数据遗漏并且/或者事件的长度是错误的；某些事件已经损坏或被覆盖，或者偏移量已经改变并且下一个事件的起始偏移量也是错误的），备库上的中继日志损坏，二进制日志于InnoDB事务日志不同步，