数据库读写分离

场景：

数据库读写分离是用来解决什么问题的？

• 读写分离，解决“数据库读性能瓶颈”问题

技术选型

 

能实现数据实时同步的技术很多，基于OS层(例如VERITAS VVR)，基于存储复制(中高端存储大多都支持)，基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的DB整库同步，会涉及到业务数据选择以及多源整合等问题，因此OS复制和存储复制多数情况并不适合做读写分离的技术首选。

基于日志的Oracle复制技术，Oracle自身组件可以实现，同时也有成熟的商业软件。选商业的独立产品还是Oracle自身的组件功能，这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

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

a.1.1、DG方案
        DG方案也叫ADG方案，英语全称Physical Standby(Active DataGuard)。支持恢复与只读并行，但由于并不是日志的逻辑应用机制，在读写分离的场景中最为局限 ，将生产机的logfiles传递给容灾机，通过Redo Apply技术来保障数据镜像能力，物理上提供了与生产数据库在数据块级的一致性镜像，也叫physical方式。Physical方式支持异步传输方式，但容灾机处在恢复状态，不可用；

a.1.2、Logical Standby
        通过SQL Apply（即Log Miner）技术，将接收到的日志文件还原成SQL语句，并在逻辑备份数据库上执行，从而达到数据一致性的目的，也叫logical 方式。logical方式只支持同步传输方式，但容灾机可以处在read-only状态

a.1.3、Stream
        最灵活，但最不稳定

a.2、选择商业化的产品
        更多出于稳定性、处理能力等考虑。市面上成熟的Oracle复制软件也无外乎几种，无论是老牌的Shareplex，还是本土DSG公司的RealSync和九桥公司的DDS，或是Oracle新贵GoldenGate，都是可供选择的目标。随着GoldenGate被Oracle收购和推广，个人认为GoldenGate在容灾、数据分发和同步方面将大行其道。

 

选择商业化的产品，更多出于稳定性、处理能力等考虑。市面上成熟的Oracle复制软件也无外乎几种，无论是老牌的Shareplex，还是本土DSG公司的RealSync和九桥公司的DDS，或是Oracle新贵Goldengate，都是可供选择的目标。随着GoldenGate被Oracle收购和推广，个人认为GoldenGate在容灾、数据分发和同步方面将大行其道。

mycat

 

转载出处：

https://baijiahao.baidu.com/s?id=1614304400276051465&wfr=spider&for=pc

 

https://www.cnblogs.com/southdom/articles/4786440.html

 

https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960806&idx=1&sn=9d70e28a0962467495c3546d58720c40&chksm=bd2d003a8a5a892ca4b1e5badd9938ffb0e18d6314b38d2cee6f2e25a7c6ffe0f73e5ce11074&scene=27#wechat_redirect