GoldenGate简介
Oracle Golden Gate软件是一种基于日志的结构化数据复制备份软件,它通过解析源数据库在线日志或归档日志获得数据的增量变化,再将这些变化应用到目标数据库,从而实现源数据库与目标数据库同步。Oracle Golden Gate可以在异构的IT基础结构(包括几乎所有常用操作系统平台和数据库平台)之间实现大量数据亚秒一级的实时复制,从而在可以在应急系统、在线报表、 实时数据仓库供应、交易跟踪、数据同步、集中/分发、容灾、数据库升级和移植、双业务中心等多个场景下应用。同时,Oracle Golden Gate可以实现一对一、广播(一对多)、聚合(多对一)、双向、点对点、级联等多种灵活的拓扑结构。
GoldenGate技术架构
和传统的逻辑复制一样,Oracle GoldenGate实现原理是通过抽取源端的redo log或者archive log,然后通过TCP/IP投递到目标端,最后解析还原应用到目标端,使目标端实现同源端数据同步。以下是OracleGoldenGate的技术架构:
Manager进程
Manager进程是GoldenGate的控制进程,运行在源端和目标端上。它主要作用有以下几个方面:启动、监控、重启Goldengate的其他进程,报告错误及事件,分配数据存储空间,发布阀值报告等。在目标端和源端有且只有一个manager进程,其运行状态为running好stopped。 在windows系统上,manager进程作为一个服务来启动,二在Linux/Unix系统上则是一个系统进程。
Extract进程
Extract运行在数据库源端,负责从源端数据表或者日志中捕获数据。Extract的作用可以按照表来时间来划分:
初始时间装载阶段:在初始数据装载阶段,Extract进程直接从源端的数据表中抽取数据。
同步变化捕获阶段:初始数据同步完成以后,Extract进程负责捕获源端数据的变化(DML和DDL)
GoldenGate并不是对所有的数据库都支持ddl操作
Extract进程会捕获所有已配置的需要同步的对象变化,但只会将已提交的事务发送到远程的trail文件用于同步。当事务提交时,所有和该事务相关的 日志记录被以事务为单元顺序的记录到trail文件中。Extract进程利用其内在的checkpoint机制,周期性的记录其读写的位置,这种机制是 为了保证Extract进程终止或操作系统当机,重新启动Extract后,GoldenGate可以恢复到之前的状态,从上一个断点继续往下运行。通过 上面的两个机制,就可以保证数据的完整性了。
多 个Extract 进程可以同时对不同对象进行操作。例如,可以在一个extract进程抽取并向目标端发生事务数据的同时,利用另一个extract进程抽取的数据做报 表。或者,两个extract进程可以利用两个trail文件,同时抽取并并行传输给两个replicat进程以减少数据同步的延时。
在进行初始化转载,或者批量同步数据时, GoldenGate会生成extract文件来存储数据而不是trail文件。默认情况下, 只会生成一个 extract文件,但如果出于操作系统对单个文件大小限制或者其他因素的考虑,也可以通过配置生成多个 extract文件。 extract文件不记录检查点。
Extract进程的状态包括Stopped(正常停止),Starting(正在启动),Running(正在运行),Abended(Abnomal End的缩写,标示异常结束)。
Pump进程
pump进程运行在数据库源端,其作用是将源端产生的本地trail文件,把trail以数据块的形式通过TCP/IP 协议发送到目标端,这通常也是推荐的方式。pump进程本质是extract进程的一种特殊形式,如果不使用trail文件,那么extract进程在抽取完数据以后,直接投递到目标端,生成远程trail文件。
与 Pump进程对应 的叫Server Collector进程,这个进程不需要引起我的关注,因为在实际操作过程中,无需我们对其进行任何配置,所以对我们来说它是透明的。它运行在目标端,其 任务就是把Extract/Pump投递过来的数据重新组装成远程ttrail文件。
注意:无论是否使用pump进程,在目标端都会生成trail文件
pump进程可以在线或者批量配置,他可以进行数据过滤,映射和转换,同时他还可以配置为“直通模式”,这样数据被传输到目标端时就可以直接生成所需的格式,无需另外操作。 直通模式提高了data pump的效率,因为生成后的对象 不需要继续进行检索。
在大多数情况下,oracle都建议采用data pump,原因如下:
1、为目标端或网络问题提供保障 :如果只在目标端配置trail文件,由于源端会将extract进程抽取的内容不断的保存在内存中,并及时的发送到目标端。当网络或者目标端出现故障时, 由于extract进程无法及时的将数据发送到目标, extract进程将耗尽内存然后异常终止。 如果在源端配置了data pump进程,捕获的数据会被转移到硬盘上,预防了 异常终止的情况。当故障修复,源端和目标端 恢复连通性时,data pump进程发送源端的trail文件到目标端。
2、 可以支持复杂的数据过滤或者转换: 当使用数据过滤或者转换时,可以先配置一个data pump进程在目标端或者源端进行第一步的转换,利用另一个data pump进程或者 Replicat组进行第二部的转换。
3、有效的规划存储资源 :当从多个数据源同步到一个数据中心时,采用data pump的方式,可以在源端保存抽取的数据,目标端保存trail文件,从而节约存储空间。
4、解决单数据源向多个目标端传输数据的单点故障: 当从一个数据源发送数据到多个目标端时,可以为每个目标端分别配置不同的data pump进程。这样如果某个目标端失效或者网络故障时,其他的目标端不会受到影响可以继续同步数据。
Replicat进程
Replicat进程,通常我们也把它叫做应用进程。运行在目标端,是数据传递的最后一站,负责读取目标端trail文件中的内容,并将其解析为DML或 DDL语句,然后应用到目标数据库中。
和Extract进程一样,Replicat也有其内部的checkpoint机制,保证重启后可以从上次记录的位置开始恢复而无数据损失的风险。
Replicat 进程的状态包括Stopped(正常停止),Starting(正在启动),Running(正在运行),Abended(Abnomal End的缩写,标示异常结束)。
Trail文件
为了更有效、更安全的把数据库事务信息从源端投递到目标端。GoldenGate引进trail文件的概念。前面提到extract抽取完数据以后 Goldengate会将抽取的事务信息转化为一种GoldenGate专有格式的文件。然后pump负责把源端的trail文件投递到目标端,所以源、 目标两端都会存在这种文件。 trail文件存在的目的旨在防止单点故障,将事务信息持久化,并且使用checkpoint机制来记录其读写位置,如果故障发生,则数据可以根据checkpoint记录的位置来重传 。 当然,也可以通过extract通过TCP/IP协议直接发送到目标端,生成远程trail文件。但这种方式可能造成数据丢失,前面已经提到过了,这里不再赘述。
Trail文件默认为10MB,以两个字符开始加上000000~999999的数字作为文件名。如c:\directory/tr000001.默认情况下存储在GoldenGate的dirdat子目录中。可以为不同应用或者对象创建不同的trail文件。同一时刻,只会有一个extract进程处理一个trail文件。
10.0版本以后的GoldenGate,会在trail文件头部存储包含trail文件信息的记录,而10.0之前的版本不会存储该信息。每个trail文件中的数据记录包含了数据头区域和数据区域。在 数据头区域中包含事务信息,数据区域包含实际抽取的数据
进程如何写trail文件
为了减小系统的I/O负载,抽取的数据通过大字节块的方式存储到trail文件中。同时为了提高兼容性,存储在trail文件中的数据以通用数据模式(一种可以在异构数据库之间进行快速而准确转换的模式)存储。 当然,根据不同应用的需求,数据也可以存储为不同的模式。
默认情况下,extract进程以追加的方式写入trail文件。当extract进程异常终止时,trail文件会被标记为需要恢复。当extract重新启动时会追加checkpoint之后的数据追加到该trail文件中。在 GoldenGate 10.0之前的版本, extract进程采用的是覆盖模式。即当 extract进程异常终止,则会将至上次完整写入的事务数据之后的数据覆盖现有trail文件中的内容。
这里是笔者理解不是很透彻,原文如下,望读者给予建议
By default, Extract operates in append mode, where if there is a process failure, a recovery marker is written to the trail and Extract appends recovery data to the file so that a history of all prior data is retained for recovery purposes.
In append mode, the Extract initialization determines the identity of the last complete transaction that was written to the trail at startup time. With that information, Extract ends recovery when the commit record for that transaction is encountered in the data source; then it begins new data capture with the next committed transaction that qualifies for extraction and begins appending the new data to the trail. A data pump or Replicat starts reading again from that recovery point.
Overwrite mode is another version of Extract recovery that was used in versions of GoldenGate prior to version 10.0. In these versions, Extract overwrites the existing transaction data in the trail after the last write-checkpoint position, instead of appending the new data. The first transaction that is written is the first one that qualifies for extraction after the last read checkpoint position in the data source.
checkpoint
checkpoint用于抽取或复制失败后(如系统宕机、网络故障灯),抽取、复制进程重新定位抽取或者复制的起点。在高级的同步配置中,可以通过配置checkpoint另多个extract或者replicat进程读取同个trail文件集。
extract进程在数据源和trail文件中都会标识checkpoint,Replicat只会在trail文件中标示checkpoint。
在批处理模式中,extract和replicat进程都不会记录checkpoint。如果批处理失败,则整改批处理会重新进行。
checkpoint信息会默认存储在goldengate的子目录dirchk中。在目标端除了checkpoint文件外,我们也可以通过配置通过额外checkpoint table来存储replicat的checkpoint信息。
Group
我们可以通过为不同的extract和replicat进程进行分组来去区分不同进程之间的作用。例如,当需要并行的复制不同的数据集时,我们则可以创建两个或者多个复制进程。
进程组中包含进程,进程文件,checkpoint文件和其他与进程相关的文件。对于replicat进程来说,如果配置了checkpoint table,则不同组的都会包含checkpoint table。
组的命名规则如下
GGSCI
GGSCI是GoldenGate Software Command Interface 的缩写,它提供了十分丰富的命令来对Goldengate进行各种操作,如创建、修改、监控GoldenGate进程等等。
Commit Sequence Number
前文已经多次提到,Goldengate是以事务为单位来保证数据的完整性的,那么 GoldenGate又是怎么识别事务的呢? 这里用到的是Commit Sequence Number(CSN)。CSN存储在事务日志中和trail文件中 ,用于数据的抽取和复制。CSN作为事务开始的标志被记录在trail文件中,可以通过@GETENV字段转换函数或者logdump工具来查看。不同的数据库平台的CSN显示如下
GoldenGate对不同数据库的支持情况
*只能作为目标端,不能作为源端。但Goldengate可以从mysql直接装载的原表中抽取数据。(由于笔者不了解mysql,这里只是在字面意思翻译,原文如下
the exception being that GoldenGate can extract records from MySQL source tables as part of a GoldenGate direct load.
** GoldenGate进行事务数据管理的API工具
*** 只支持镜像复制,不支持数据操作、过滤,字段映射等。