小论goldengate 的局限

 本人算是oracle的粉丝，所以对oracle收购了的goldengate也心存莫名欣赏，本来想去了解shareplex的，但自从goldengate属于oracle，便开始了解、试用goldengate。goldengate确有安装简单、节省带宽、跨平台、灵活复制的优势，但在现实使用中，并不得心应手。根据切身感受和分析，goldengate还是有它的适用范围和局限的。

一、适用范围

goldengate原本就是一个数据抽取的工具，而不是现在oracle所标榜的“数据复制”和“容灾”。它可以用作etl的抽取工具，可以用于小系统的报表分离，可以用于异地的数据同步。

二、局限

1.由于当前版本ddl和dml复制的实现方式不同，前者变更时，通过trigger写入表中，gg是通过读表，将ddl信息写入trail，而后者gg是通过读redo log、archivelog等，将变化信息读入trail，若配置gg读archivelog模式，或者从redo中读取失败，需要从archivelog中读时，则ddl比dml的trail至少要早一个日志切换的时间，就可能出现应用报错的现象。所以版本发布时，不要将ddl和dml混起来执行，同时最好取消ddl复制，手工在两端执行ddl。

2.双向复制的冲突处理有局限。gg的冲突处理可以基于主节点或是时间点的方式，而并不能做到按业务逻辑和关系去同步，这就极容易导致业务逻辑的错误。举个例子，两端db同时对表的一个值加10和减20的操作，不管选择哪种冲突处理机制，gg同步的都是最终的值，而不管将那端的值同步到另一端，都是错误的。

3.在实际中，常常碰到，本来两端数据是一致的，跑着跑着就不一致了，还找不出确切原因。

4.gg不能将两端不同步的数据同步，而只能在两端同步的基础上同步变化数据，这就导致了gg没有自我修复功能，一旦一时少了数据，那一直少数据，而且若原库对相关数据操作，那么gg端同步必报错。

5.性能与准确率的矛盾。在大数据量大并发的系统中，日志的读取或许就成了gg的瓶颈，单进程入库效率就更低了。gg是以事物为单位来抽取和应用的，但不能保证不同事物的逻辑。 若采用多进程抽取和入库，就存在极大的准确性风险。