Replication延时的类型
1. 固定性的延时
——Slave的数据持续性的落后于Master并且一直无法与Master的数据保持一致。
——Slave的数据经常在白天落后于Master，而在晚上可以赶上并与Master的记录保持一致。
这种类型的延时通常是由于Slave服务器的负载已经到达了上限或在白天访问量大的时候到达上限造成的。
2. 非固定性的延时
——Slave的数据只是短暂的落后于Master，可在短时间内恢复
这类型的延时通常与批量任务和报表有关，效率差的查询也会导致这类延时
Mysql Replication的限制
Mysql的Replication是单线程的，意味着只能有效的使用一个CPU内核和一个磁盘，一条复杂的查询或者事务都导致进程被阻塞，不过现在针对5.1版本的多线程Replication补丁，，还是pre版，有很多限制，感兴趣的可以去看看。
Replication的容量
1. 理解什么是Replication的容量
可以将Replication暂停一个小时，重新启动Replication后，观察Slave的数据多久可以与Master一致。从
Replication重新启动到和Master数据一致所花费的时间与Replication暂停的时间的比值就是Replication的容量。
2. 建议保持Replication的容量在3倍以上，即延迟一个小时的数据，Slave只需要20分钟就能与Master的数据一致。
Replication的优化
1. 5.0的mysql中避免类似以下的更新语句
INSERT … SELECT
UPDATE .... WHERE
复杂的查询会导致Replication线程阻塞。如果是insert或update与select结合的语句，可以讲select单独执行并保存在临时表中，然后再执行insert或者update。
如果使用的是5.1的mysql，新功能中的行级Replication（RBR）可以解决这个问题。RBR可以将在Master上通过复杂查询后更新的结果直接传给Slave，Slave可以直接将结果更新到数据库中。
2. 避免大的事务
太大的事务会造成Replication长时间阻塞，数据会严重滞后于Master。
Slave服务器的硬件选择
更快的CPU内核，对于单线程的Replication多核CPU是没有任何优势的。
更高速的硬盘，包括更高的转速和更好的高速缓存命中率，如果有钱的话上SSD吧
主从结构的扩展性问题
1. 如何降低写操作的频率
Master的写操作会扩散到所有的Slave上，所以高频率的写操作会降低Slave的读操作效率。
至少保持一台Slave做全库同步，其他的Slave可以只做部分表的同步。当然，这需要web应用程序的配合来分配哪些查询读哪些Slave。
将一些更新操作放到memcached中，例如session和计数器。
Slave使用myisam引擎
将一些写入量很大的更新操作直接在slave上执行，而不通过Replication。
2. 如何更有效的利用Slave的硬件资源
使用分区
有选择的对表进行同步
在Slave上对数据进行归档。
Session的持久化
为不同的应用服务器分配不同的Slave进行读操作。
或者根据查询类型的不同来分配不同的Slave。
3. 如何使你的程序最大化的利用Slave
将对数据更新不敏感的查询放到Slave上，而需要实时数据的查询则放到Master。
通过session的持久化，让做了修改的用户首先看到修改的内容，其他的用户可以等待Slave更新后再查看新内容。
对于某些数据，可以用memcached来存放数据的版本号，读Slave的程序可以先对比Slave的数据和memcached数据的版本，如果不一致则去读master。用户和博客类的信息可以用这种方法。
在查询前可以通过SHOW SLAVE STATUS检测Slave的状态，然后根据返回的结果进行服务器的选择。
阅读(1414) | 评论(0) | 转发(0) |
