读写分离

Mysql

主要思路:

第一步:先做mysql的主从(Master/Slave Replication),实现数据同步
第二部:通过Amoeba来实现读写分离,也可以通过mysql proxy(比较麻烦)。
总结

1.当MySQL主从复制在 show slave status\G 时出现Slave_IO_Running或Slave_SQL_Running 的值不为YES时,需要首先通过 stop slave 来停止从服务器,然后再执行一次本文 2.1与2.2 章节中的步骤即可恢复,但如果想尽可能的同步更多的数据,可以在Slave上将master_log_pos节点的值在之前同步失效的值的基础上增大一些,然后反复测试,直到同步OK。因为MySQL主从复制的原理其实就是从服务器读取主服务器的binlog,然后根据binlog的记录来更新数据库。

2.MySQL-Proxy的rw-splitting.lua脚本在网上有很多版本,但是最准确无误的版本仍然是源码包中所附带的lib/rw-splitting.lua脚本,如果有lua脚本编程基础的话,可以在这个脚本的基础上再进行优化;

3.MySQL-Proxy实际上非常不稳定,在高并发或有错误连接的情况下,进程很容易自动关闭,因此打开--keepalive参数让进程自动恢复是个比较好的办法,但还是不能从根本上解决问题,因此通常最稳妥的做法是在每个从服务器上安装一个MySQL-Proxy供自身使用,虽然比较低效但却能保证稳定性;

4.一主多从的架构并不是最好的架构,通常比较优的做法是通过程序代码和中间件等方面,来规划,比如设置对表数据的自增id值差异增长等方式来实现两个或多个主服务器,但一定要注意保证好这些主服务器数据的完整性,否则效果会比多个一主多从的架构还要差;

5.MySQL-Cluster 的稳定性也不是太好;

6.Amoeba for MySQL 是一款优秀的中间件软件,同样可以实现读写分离,负载均衡等功能,并且稳定性要大大超过MySQL-Proxy,建议大家用来替代MySQL-Proxy,甚至MySQL-Cluster。


oracle

1. 主库负责写数据、读数据。读库仅负责读数据。每次有写库操作,同步更新cache,每次读取先读cache在读DB。写库就一个,读库可以有多个,采用dataguard来负责主库和多个读库的数据同步。

对于,其他类型的数据,博客的日志表,电商的订单表,支付公司的交易流水表都可以采用分库分表的形式。

2. Writer DB和Reader  DB采用日志复制软件实现实时同步; Writer DB负责交易相关的实时查询和事务处理,Reader DB负责只读接入,处理一些非实时的交易明细,报表类的汇总查询等。同时,为了满足高可用性和扩展性等要求,对读写端适当做外延,比如Writer DB采用HA或者RAC的架构模式,Reader DB可以采用多套,通过负载均衡或者业务分离的方式,有效分担读库的压力。
基于日志的Oracle复制技术,Oracle自身组件可以实现,同时也有成熟的商业软件。选商业的独立产品还是Oracle自身的组件功能,这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

采用Oracle自身组件功能,无外乎Logical Standby、Stream以及11g的Physical Standby(Active Data Guard),对比来说,Stream最灵活,但最不稳定,11g Physical Standby支持恢复与只读并行,但由于并不是日志的逻辑应用机制,在读写分离的场景中最为局限。如果技术团队对相关技术掌握足够充分,而选型方案的处理能力又能支撑数据同步的要求,采用Oracle自身的组件完全可行。

------------------------

dataguard这个是数据库容灾的一种模式,是指在正常运行的生产环境之外异地运行的数据库设备(有自己独立的数据库磁阵),如果生产环境发生数据变动,通过dataguard将变动的数据操作从生产环境实时同步过来,保证了生产环境和容灾环境的数据的一致性,如果生产环境数据库瘫痪了,容灾环境就接管过来。
Data Guard可以以只读的方式打开数据库,但此时Media Recovery利用日志进行数据同步的过程就停止了,如果物理备用数据库处于恢复的过程中数据库就不能打开查询,也就是说日志应用和只读打开两个状态是互斥的。
Oracle 11g 中推出的Active Data Guard功能解决了这个矛盾,在利用日志恢复数据的同时可以用只读的方式打开数据库,用户可以在备用数据库上进行查询、报表等操作,这类似逻辑Data Guard备用数据库的功能(查询功能方面),但是,数据同步的效率更高、对硬件的资源要求更低。这样可以更大程度地发挥物理备用数据库的硬件资源的效能。
相关文章
相关标签/搜索