高性能mysql学习笔记--复制

高性能mysql
十：复制
1，复制的概述
复制解决的基本问题是让一台服务器的数据与其他服务器要保持同步。
两种方式：基于行的复制和基于语句的复制，都是通过在主库上记录二进制日志，在备库上重放日志来实现异步的数据复制的。复制通常不会增加主库的开销，主要是启用二进制日志带来的开销，但是处于备份或及时从奔溃中恢复的目的，这点开销是必要的。
复制的用途：数据分布，负载均衡，备份，高可用和故障切换，mysql升级测试。
2，配置复制
1,在每台服务器上创建复制账号：
grant replication slave,replication client on *.* to repl@'192.168.0.%' identified by     'p4ssword'
注意我们把这个账号限制在本地网络，因为这是一个特权账号。
2,配置主库和备库
在主库上打开二进制日志并指定一个独一无二的服务器id，修改my.cnf，重启服务器
log_bin = mysql_bin
server_id = 10
备库上也修改my.cnf，重启服务器
log_bin = mysql-bin
server_id = 2 （必须的）
relay_log = /var/lib/mysql/mysql-relay-bin (指定中继日志位置和命名)
log_slave_updates = 1
read_only = 1
3,通知备库连接到主库并从主库复制数据。
命令：
change master to master_host='主库名'，
master_user='repl'，
master_password='p4ssword',
master_log_file='mysql-bin.000001',
master_log_pos=0;
master_log_pos设置为0，因为要从日志的开头读起。

运行start slave 开始复制

4，从另外一个服务器开始复制
前面的设置都是假定主备库均为刚刚安装好且都是默认的数据，但是大多情况下，主库已经运行了一段时间，然后安装备库，
有几种方法来初始化备库或者从其他服务器克隆数据到备库，包括从主库复制数据，从另外一台备库客隆数据，以及使用最近的一次备份来启动备库，需要有三个条件保持同步：
在某个时间点的主库的数据快照。
主库当前的二进制日志文件，和获得数据快照时在该二进制文件中的偏移量，我们把这两个值称为日志文件坐标，通过这两个值可以确定二进制日志的位置，通过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：一款开源的热备份工具。
使用另外的备库：
2.5 推荐的复制配置
在主库上二进制日志最重要的选项时sync_binlog：sync_binlog=1
开启选项，mysql每次在提交事务前会将二进制日志同步到磁盘上，保证在服务器崩溃时不会丢失事务。
Innodb：

10.3 复制的原理
3.1 基于语句的复制
好处：简单，简单的记录和执行这些语句，能够让主备保持同步，另一个好处是二进制日志的事件更加紧凑，

坏处：

3.2 基于行的复制
好处：最大的好处是正确的复制每一行，一些语句可以被更加有效的复制

坏处：当进行全表更新的时候，基于行的复制开销会很大。

3.4 复制文件
除了二进制日志和中继日志文件，还有其他文件需要用到：
mysql-bin.index:
当服务器上开启二进制日志时，会同时生成一个和二进制同名的但以.index作为后缀的文件，该文件用于记录磁盘上的二进制日志文件。
mysql-relay-bin-index：
这个文件时中继日志的索引文件，和mysql-bin.index的作用类似
master.info:
这个文件用于保存备库连接到主库所需要的信息，
relay-log.info:
这个文件包含了当前备库复制的二进制日志和中继日志坐标
使用这些文件时一种粗糙的方式，他们不是同步写的，当断电并且数据没有被刷新到磁盘的时候，重启服务器后，文件记录的可能是错的，5.5后有改进
以.index作为后缀的文件也与设置expire_log_days存在交互，该参数定义了mysql清理过期日志的方式，如果mysql-bin.index在磁盘上不存在，某些mysql版本自动清理就会没用，最好是显式的执行一些日志清理策略，比如设置expire_logs_days或者其他方式。
3.5 发送复制事件到其他备库
log_slave_updates选项可以让备库变成其他服务器的主库，
3.6复制过滤器
复制过滤选项允许你仅复制服务器上一部分数据，有两种方式：在主库上过滤记录到二进制日志的事件，以及在备库上过滤记录到中继日志事件，

使用选项binlog_do_db和binlog_ignore_db来控制过滤，在备库上，可以通过设置replicate_*选项，在从中继日志中读取事件时进行过滤，

总的来说，复制过滤时随时可能会发生问题。
10.4 复制拓扑
可以在任意个主库和备库之间复制，只有一个限制：每一个备库只能有一个主库。
基本原则：一个mysql备库实例只能有一个主库，
每个备库必须有一个唯一的服务器id
一个主库可以有多个备库，
如果打开了log_slave_updates选项，一个备库可以把其主库上的数据变化传播到其他备库。
4.1 一主库多备库
在有少量写和大量读时，这种配置是非常有用的。
用途：
为不同角色使用不同的备库
把一台备库当作待用的主库，除了复制没有其他数据传输
将一台备库放在远程数据中心，用作灾难恢复
延迟一个或多个备库，以备灾恢复
使用其中一个备库，作为备份，培训，开发或者测试使用服务器
4.2 主动 - 主动模式下的主 - 主复制

mysql5.0增加设置auto_increment_increment和auto_increment_offset ，可以让mysql自动为insert语句选择不互相冲突的值，然而允许向两台主库上写入冷然很危险，
4.3 主动-被动模式下的主-主复制

这种方式使得反复切换主动和被动服务器非常方便，因为服务器的配置是对称的。这使得故障转移和故障恢复很容易。
设置：
1，确保两台服务器上有相同的数据
2，启动二进制日志，选择唯一的服务器id，并创建复制账号
3，启动备库更新的日志记录
4，把被动服务器配置成只读，防止可能与主动服务器上的更新产生冲突，这点是可选的（不懂啊，为啥要设置成只读）
5，启动诶个服务器的mysql实例
6，将每个主库设置为对方的备库，使用新创建的二进制日志开始工作

不懂：事件服务器id与主动服务器的相同
4.4 拥有备库的主-主结构

优点：增加了冗余，对于不同地理位置的复制拓扑，能够消除站点单点失效的问题，你也可以像平常一样，将读查询分配的备库上
4.5 环形复制
环形结构可以有三个或更多的主库，每个服务器都是它之前的服务器的备库，是在它之后的服务器的主库。

缺点：没有对称配置和简单的故障转移，并且完全依赖与环上的每一个可用节点，这大大增加了整个系统的失效几率，总的来说，环形结构非常脆落，尽量避免
总结：就是不要用了呗

环形结构的优化，但是还是不建议用吧，太花里胡哨了
4.6 主库，分发主库以及备库
我们之前说过当备库足够多时，会对主库造成很大的负载，每个备库都会在主库上创建一个线程，并执行binlog dump命令。该命令会读取二进制日志文件中的数据并将其发送给备库，而且备库之间不会共享binlog dump资源。
所以，当需要多个备库时，一个好办法就是从主库移除负载并使用分发主库

其实就是需要一个库专用用于连接备库，这个分发主库其实也算是备库。
4.7 树或金字塔形
如果正在将主库复制到大量的备库中，不管是把数据分发到不同的地方，还是提供更高的读性能，使用金字塔结构都能够更好的管理。

4.8 定制的复制方案
选择行复制
每个备库只拥有主库的一部分数据，并且将读分配给备库，
分离功能

工作上：出报表就属于在线数据分析，可以单独分离出来一个备库使用
数据归档
备库上保留主库上删除的数据，
我的理解：就是分裤分表，将一些历史数据分离出来，因为历史数据一般用不到。
将备库用作全文检索
只读备库
通过设置read_only选项来实现
模拟多主库复制
可以通过一台备库轮流指向多台主库的方式来模拟多主库复制
就是间歇性指向主库，一会指向主库a，一会指向主库b
创建日志服务器
使用mysql复制的另一种一用途就是创建没有数据的日志服务器，它唯一的目的就是更加容易重放并且/或者过滤二进制日志事件。

10.5 复制和容量规划
无法复制扩展写操作：复制只能扩展读操作，无法扩展写操作。
前面说大的主-主拓扑并为两个服务器执行写操作，这种配置比主备结构能支持稍微多一点的写入，但是性能很低。
5.3 规划冗余容量
10.6 复制管理和维护
6.1 监控复制
在主库上，可以使用show master status命令来查看当前主库的二进制日志位置和配置，
show binlog events来查看复制事件。
6.2 测量备库延迟
show slave status 输出的seconds_behind_master列理论上显示了备库的延时，但是并不准确，
所以一般是忽略seconds_behind_master的值，使用heartbeat record，这是一个在主库上会每秒更新一次的时间戳（心跳），可以用备库当前的时间戳减去心跳记录的值来计算延时，
6.3 确定主备是否一致

6.4 从主库重新同步备库
最简单的办法是使用mysqldump转存受影响的数据并重新导入。

6.5 改变主库
在计划内操作，只需要在备库简单地使用change master to 命令，并制定合适的值，整个过程中最难的是获取新主库上合适的二进制日志位置，这样备库才可以从和老主库相同的逻辑位置开始复制。
把备库提升为主库要更困难一点：
计划内的提升：
1，停止向老的主库写入
2，让备库追赶上主库（可选）
3，将一台备库配置为新的主库
4，将备库和写操作指向新的主库，然后开始主库的写入
计划外的提升：
1，确定哪台备库的数据最新，检查每台备库上show slave status命令的输出，选择其中
master_log_file/read_master_log_pos的值最新的那个
2，让所有备库执行完所有其从崩溃前的旧主库获得的中继日志，如果在未完成前修改备库的主库，他会抛弃剩下的日志事件，从而无法获知该备库在什么地方停止。
3，执行前一节的5-7步（没记，书中），
4，比较每台备库和新主库的mater_log_file/read_master_log_pos的值
5，执行前一节的10-12步（没记，书中）

10.7 复制的问题和解决方案
此处较多，适合多看书，多看，当遇到的话及时解决。