Oracle10g版本DataGuard通过以下三种机制实现主备之间的同步:
- Redo Transport Services
- Log Apply Services
- Fetch archive log(FAL)
Redo传输服务(Redo Transport Service),负责主备之间redo data的传输和接收。这里的redo data可以是archive log也可以是online redo data。
Primary端,DataGuard可以选择使用归档进程(ARCn)或是日志写进程(LGWR)收集redo data并传输到Standby端。
注意:不能同时使用ARCn和LGWR进行传输redo data到同一个地址,但是你可以使用LGWR归档日志,使用ARCn传输redo data到另外一个地址,这需要定义不同的log_archive_dest_n参数。
另外,当主备之间出现GAP时,DataGuard通过FAL机制进行GAP archive log的自动检查和传输。
1 Using Archiver Processes (ARCn) to Archive Redo Data
默认,redo传输服务使用ARCn进程归档online redo log,但是仅在dataguard的最大性能保护模式上使用ARCn进程传输redo data,这是因为最大性能保护模式并不要求主备之间的实时同步,符合支持ARCn传输archive log的异步模式环境,而dataguard的其他两种模式则对主备之间的实时同步要求比较高。
DataGuard的其他两种保护模式(最高可用性和最大保护)必须使用LGWR进程传输redo data到standby端。
1.1 ARCn Archival Processing
DataGuard最大性能模式下,主备之间通过ARCn进程传输redo data的过程如下:
1. Primary端,ARC0进程归档online redo log至本地的LOG_ARCHIVE_DEST_1位置
2. ARC0归档完成后,ARC1进程传输该归档日志文件至本地LOG_ARCHIVE_DEST_2定义的Standby端
Primary上的这两步基本上没有争议,但standby端如何接收并apply归档日志一直没有确认,官方文档上这一段也写的相当不负责任。以至于google到的也主要有两种说法,如下:
观点1,参见《oracle实验记录 (oracle 10G dataguard(4)redo传输&进程)》:
1. standby rfs进程将redo写到 standby redo logfile中
2. standby的ARCn进程将standby redo logfile中的数据归档
3. standby的mrp(redo apply)或者lsp(sql apply)进程应用这些归档中的redo到standby database
这种观点认为,standby端由RFS进程接收由ARC1进程传过来的archive log并写入到本地的standby redo logfile中,然后在本地再次归档,然后由MRP进程(redo apply)或是LSP进程(sql apply)应用这些redo data至standby database里。
观点2,参见《physical data guard (Standby)的原理》:
1. RFS进程接收primary端传送的archive log
2. MRP进程使用此archive log进行redo apply
这种观点认为,standby端接收archive log后直接由MRP进程进行redo apply,并不使用standby redo logfile。
个人同意观点2,因为使用ARCn进程传输archive log至standby端时,主备之间至少已经有一个archive log的GAP了,既然并非real-time sync,所以此时ORACLE没有必要将传输过来的archive log解析后重新写入standby redo logfile,然后应用到本地库后再重新归档,完全可以直接apply了。
2 Using the Log Writer Process (LGWR) to Archive Redo Data
ARCn传送的是archive log,LGWR的传输机制与之不同,不再需要等待primary端的online redo logfile切换及归档后才开始传输。
Standby端apply节点的LGWR进程会选择一个standby redo logfile对应着primary端redo log的sequence号及大小。这样,当primary端有redo产生的时候,redo data也会传送至standby端。
根据LOG_ARCHIVE_DEST_n参数定义的SYNC或是ASYNC属性,LGWR传输redo data可以分为同步和异步两种方式。
注意:
1. 同步方式只能在DataGuard的最大保护(maximum protection)或是最高可用(maximum availability)的模式下实现,因为最大性能模式(max perfermance)的机制就是异步的。
2. redo传输服务必须在primary库的LOG_ARCHIVE_DEST_n参数定义LGWR以及SERVICE属性,才能使用LGWR进程传输redo data至standby端
2.1 LGWR SYNC Archival Processing
LGWR SYNC方式,需要在primary端配置参数如下:
LOG_ARCHIVE_DEST_1='LOCATION=/arch/' LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC NET_TIMEOUT=30' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE |
注意:LOG_ARCHIVE_DEST_2定义的”SERVICE=standby”,其中standby取值本地tnsnames.ora定义的standby apply node的Oracle Net名称。
LGWR SYNC传输redo data的过程如下:
1. Primary端产生redo data后,LGWR进程将redo data写入online redo logfile,同时提交redo data给多个网络服务(LNSn)进程
2. LNSn进程通过ORACLE Net服务将redo data传送至standby端
3. Standby端的RFS进程接收传输过来的redo data后,负责写入standby database上的standby redo logfile里。
4. 直到standby端所有定义了LGWR SYNC的LOG_ARCHIVE_DEST_n地址都接收完传过来的redo data后,primary端transactions才会commit
Primary端的log switch会触发standby上的日志切换,启动standby上的ARCn进程归档standby redo logfile。然后,MRP(redo apply)或者LSP(sql apply)进程将会应用redo data到standby database。
如果使用real-time apply,当RFS进程将redo data写入至standby redo logfile里,DataGuard会直接从current standby redo logfiles恢复redo data。
2.2 LGWR ASYNC Archival Processing
LGWR ASYNC方式,需要在primary端配置参数如下:
LOG_ARCHIVE_DEST_1='LOCATION=/arch/' LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE |
注意:异步机制下,primary端不需要确认standby端的网络传输,故不用设置NET_TIMEOUT参数。
与同步模式不同的是,LGWR ASYNC不再等待Standby端的redo data传送完毕后才提交事务,流程如下:
1. Primary端产生redo data后,LGWR进程将redo data写入online redo logfile
2. 网络服务LNSn进程通过ORACLE Net服务非同步的将redo data传送至standby端
3. Standby端的RFS进程接收传输过来的redo data后,并负责写入standby database上的standby redo logfile里。
4. primary端LGWR不用确认LNSn进程的传输状态,直接将新的redo data写入online redo logfile
异步模式下的redo data recover与LGWR SYNC原理一样。
---最后总结---