1. OverView
两种：基于statment 基于row(5.1)
将master的binlog在slave replay，不保证延迟时间，可能秒分甚至小时
解决的问题：
数据分发
负载均衡
备份：有价值，但是slave既不是backup也不适用于backup
HA，failover
测试Mysql升级
步骤
master在binlog中记录
slave将binlog拷贝到他的relay log
slave replay
2. 设置replication
建账号 授权
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*
-> TO repl@'192.168.0.%' IDENTIFIED BY 'p4ssword';
启动
SHOW MASTER STATUS;
mysql> CHANGE MASTER TO MASTER_HOST='server1',
-> MASTER_USER='repl',
-> MASTER_PASSWORD='p4ssword',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=0;
SHOW SLAVE STATUS
开始replication：mysql> START SLAVE;
从已经存在的server上初始化一个新的server
cold copy：关闭master 拷贝文件
warm copy；只用MyISAM 可以使用mysqlhotcopy
mysqldump：只用InnoDB 导出数据 导入slave 将slave的coordinate修改为master binlog的适当位置
LVM snapshot/backup：
另外一个slave：使用mysqldump --master-data失效，show slave status查看位置，缺点是如果slave已经不同步拷贝也会出问题
推荐配置
sync_binlog=1：每次事务提交都写入binlog，否则server crash会丢失数据；slave这个不重要
skip_slave_start：crash之后禁止slave自动重启
read_only：防止大部分普通用户修改非临时文件
log_slave_updates: slave记录binlog，作为其他slave的master
replication filter：只同步一部分
3. replication拓扑结构
一主多从
slave可以用于不同目的，如使用不同index、使用不同存储引擎
与其他结构相比简单
两主互从,Active-Active mode
多用户特殊目的，每个master只关系自己的本地可写数据
最大问题是处理冲突
！！！一个slave多个Master是不支持的
两主,Active-passive mode
其中一个是只读的passive server
主从切换很容易
Master-Master with Slaves
能提供额外冗余
环状结构
三个或以上的master
容易fail，尽量避免
Master, Distribution Master, and Slaves
每个slave单独线程，使用binlog dump命令从binlog读取数据，并不共享资源
Blackhole storage engine：任何写入到此引擎的数据均会被丢弃掉， 不做实际存储；Select语句的内容永远是空；但是MySQL还是会正常的记录下Binlog，而且这些Binlog还会被正常的同步到Slave上
缺点：slave很难提升为master
Tree or Pyramid
减轻了master负载
一个server down 影响多个
中间层越多，处理failure越难越复杂
个性化replication方案
选择性replication：每个slave包含master一部分数据，更有效利用slave，类似于数据partition，但是master含有所有的数据。
实现的最简单方法：将数据存放于master的不同db，例如其中一个slave的配置replicate_wild_do_table = sales.%
filter也很有用，如果网络开销很大，使用filter将不需要的entry从log 过滤掉
Separating functions
将不同需要的查询分开：OLTP小而快 OLAP大而长可容延迟；oltp做master olap用slave，硬件配置按需
Data archiving：master删除数据，slave保存
将delete过滤掉，不计入binlog：在删除数据的进程中设置SET SQL_LOG_BIN=0；缺点：任何修改也不记录
slave使用replicate_ignore_db 规则
Using slaves for full-text searches
MyISAM内置支持
Creating a log server：无数据，只是replay/filter binlog
recovery的优点：快、进程可见、异常容易处理、容易过滤replication、
4. Replication and Capacity Planning
replication很难增加写能力
只有sharding(partition)能增加写能力
master-master也不能增加写：两个server顺序的写 还不如一个server并行的写
不充分使用资源：这样能更好处理peak、slow query
5. Replication管理和维护
监视replication：主要问题集中在slave，是否完成，是否有错误？
查看master：SHOW MASTER LOGS
测试slave延迟：
SHOW SLAVE STATUS不一定准确
可以使用heartbeat record；mk-heartbeat script, included in Maatkit
slave是否与master一致：
检查一直性应该是一个例行工作
CHECKSUM TABLE是内置工具，但是在replication运行的时候不可行
Maatkit has a tool called mk-table-checksum
将slave与master重新同步
传统方法，停slave，clone master
最简单方法：锁master的表，dump数据，导入到slave
如果server压力大，网络expensive也很麻烦
mk-table-sync
改变master：为slave执行新的master
CHANGE MASTER TO
最困难的是指定新master的position
将slave提升为master更困难，简单来说：master停止写；slave的replication赶上；将slave配置为master；将slave与写操作配置到新master
master-master结构更复杂：blablabla......
master崩溃：
确定那个最新；所有slave执行完relay；stop slave；change master to；新master的binlog与show master status一致
比较每个slave的Master_Log_File/Read_Master_Log_Pos与新master 一致
activate events on the new master；client连接到master；所有slave "change master to"
以上需要log_bin and log_slave_updates 的状态为enabled
Locating the desired log positions
CHANGE MASTER TO需要指定slave最后的event对应于master的位置
Switching Roles in a Master-Master Configuration(active-passive)
最重要是同一时刻只能有一个master可写：
1. stop write
2. active server:SET @@global.read_only := 1
3. active server:SHOW MASTER STATUS 记下binlog坐标
4. passive server：SELECT MASTER_POS_WAIT();
5. passive server：SET @@global.read_only := 0
6. 应用想passive写数据
