RAC環境中threads變動後如何確保goldengate繼續正常複製

轉載:http://www.easyora.net/blog/goldengate_rac_threads_remap.html

        當rac節點變動的時候，好比咱們添加或者刪除了集羣中的節點，理所固然會對節點對應的log threads進行添加或者刪除，但會形成goldengate的map log threads的順序發生紊亂。在進行這一類行爲變動的時候，特別須要注意goldengate端也須要進行特別處理。

         好比，在節點添加以前，goldengate map log threads順序以下(數據庫log thread在後，下同)：

         1—>1 (假設是sequence 100，rba 1001)

         2—>2(假設是sequence 88，rba 3009）

        當添加節點後，map log threads的順序會變成：

        1—->3(sequence 88，rba 3009）

        2—->1(sequence 100，rba 1001)

        3—->2(new)

        當ogg從新工做的時候，由於此時map的順序發生了變化，所以會形成抽取進度出現問題。

 

 

        若是有足夠的處理時間，簡單而又安全的作法是中止源端應用，刪除extract進程後，從新配置新的extract進程並從當前開始抽取。但在這段時間內，全部的操做需確保在應用已經中止服務的前提下，不然數據將形成丟失或者不一致，須要手工處理或者從新初始化。

        若是應用沒法停機呢？咱們能夠將新建的extract進度修改爲中止以前的進度狀態，從而避免操做過程當中應用的停機行爲。

        須要咱們特別記錄的checkpoint有：Current Checkpoint、Recovery Checkpoint以及Write Checkpoint

1.正常中止extract(略)

2.得到extract的checkpoint記錄

  GGSCI (node1) 21> info ext_r1 showch

EXTRACT    EXT_R1    Last Started 2011-08-16 22:35   Status STOPPED 
Checkpoint Lag       00:00:00 (updated 00:06:21 ago) 
Log Read Checkpoint  Oracle Redo Logs 
                     2011-08-17 03:32:48  Thread 1, Seqno 62, RBA 29890576 
Log Read Checkpoint  Oracle Redo Logs 
                     2011-08-17 03:32:34  Thread 2, Seqno 42, RBA 18674704

Current Checkpoint Detail:

Read Checkpoint #1

  Oracle RAC Redo Log

  Startup Checkpoint (starting position in the data source): 
    Thread #: 1 
    Sequence #: 61 
    RBA: 32112656 
    Timestamp: 2011-08-16 22:34:53.000000 
    SCN: 0.3743980 (3743980) 
    Redo File: +DATA1/my/onlinelog/group_1.261.758327805

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source): 
    Thread #: 1 
    Sequence #: 62 
    RBA: 29890576 
    Timestamp: 2011-08-17 03:32:48.000000 
    SCN: 0.3811675 (3811675) 
    Redo File: +DATA1/my/onlinelog/group_2.262.758327805

  Current Checkpoint (position of last record read in the data source): 
    Thread #: 1 
    Sequence #: 62 
    RBA: 29890576 
    Timestamp: 2011-08-17 03:32:48.000000 
    SCN: 0.3811675 (3811675) 
    Redo File: +DATA1/my/onlinelog/group_2.262.758327805

  BR Previous Recovery Checkpoint: 
    Thread #: 1 
    Sequence #: 0 
    RBA: 0 
    Timestamp: 2011-08-16 22:35:09.416136 
    SCN: Not available 
    Redo File:

  BR Begin Recovery Checkpoint: 
    Thread #: 1 
    Sequence #: 62 
    RBA: 22437392 
    Timestamp: 2011-08-17 02:35:11.000000 
    SCN: 0.3798208 (3798208) 
    Redo File:

  BR End Recovery Checkpoint: 
    Thread #: 1 
    Sequence #: 62 
    RBA: 24120320 
    Timestamp: 2011-08-17 02:35:16.000000 
    SCN: 0.3801192 (3801192) 
    Redo File:

Read Checkpoint #2

  Oracle RAC Redo Log

  Startup Checkpoint (starting position in the data source): 
    Thread #: 2 
    Sequence #: 41 
    RBA: 25323024 
    Timestamp: 2011-08-16 22:34:40.000000 
    SCN: 0.3743980 (3743980) 
    Redo File: +DATA1/my/onlinelog/group_3.266.758328125

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source): 
    Thread #: 2 
    Sequence #: 42 
    RBA: 18674704 
    Timestamp: 2011-08-17 03:32:34.000000 
    SCN: 0.3811674 (3811674) 
    Redo File: +DATA1/my/onlinelog/group_4.267.758328125

  Current Checkpoint (position of last record read in the data source): 
    Thread #: 2 
    Sequence #: 42 
    RBA: 18674704 
    Timestamp: 2011-08-17 03:32:34.000000 
    SCN: 0.3811674 (3811674) 
    Redo File: +DATA1/my/onlinelog/group_4.267.758328125

  BR Previous Recovery Checkpoint: 
    Thread #: 2 
    Sequence #: 0 
    RBA: 0 
    Timestamp: 2011-08-16 22:35:09.416136 
    SCN: Not available 
    Redo File:

  BR Begin Recovery Checkpoint: 
    Thread #: 2 
    Sequence #: 42 
    RBA: 15242240 
    Timestamp: 2011-08-17 02:35:02.000000 
    SCN: 0.3800455 (3800455) 
    Redo File:

  BR End Recovery Checkpoint: 
    Thread #: 2 
    Sequence #: 42 
    RBA: 15242240 
    Timestamp: 2011-08-17 02:35:02.000000 
    SCN: 0.3800455 (3800455) 
    Redo File:

Write Checkpoint #1

  GGS Log Trail

  Current Checkpoint (current write position): 
    Sequence #: 3 
    RBA: 51132 
    Timestamp: 2011-08-17 03:32:48.695373 
    Extract Trail: /opt/ggs/dirdat/r1/ex

Header: 
  Version = 2 
  Record Source = A 
  Type = 6 
  # Input Checkpoints = 2 
  # Output Checkpoints = 1

File Information: 
  Block Size = 2048 
  Max Blocks = 100 
  Record Length = 4096 
  Current Offset = 0

Configuration: 
  Data Source = 3 
  Transaction Integrity = 1 
  Task Type = 0

Status: 
  Start Time = 2011-08-16 22:35:10 
  Last Update Time = 2011-08-17 03:32:48 
  Stop Status = G 
  Last Result = 402

3.新建extract進程。

GGSCI (node1) 34> ADD EXT ext_r1, BEGIN NOW, TRANLOG, THREADS 3

2011-08-17 03:52:26  INFO    OGG-01749  Successfully registered EXTRACT EXT_R1 to start managing log retention at SCN 3826107. 
EXTRACT added.

4.修改current checkpoint (注意每一個thread都要修改)

GGSCI (node1) 35> alter EXTRACT ext_r1, TRANLOG, EXTSEQNO 62, EXTRBA 29890576,thread 1 
EXTRACT altered.

GGSCI (node1) 36> alter EXTRACT ext_r1, TRANLOG, EXTSEQNO 42, EXTRBA 18674704,thread 2

EXTRACT altered.

5. 修改recovery checkpoint (注意每一個thread都要修改)

GGSCI (node1) 42> ALTER EXTRACT ext_r1, IOEXTSEQNO 62, IOEXTRBA 29890576,thread 1

GGSCI (node1) 42> ALTER EXTRACT ext_r1, IOEXTSEQNO 42, IOEXTRBA 18674704,thread 2

6. 修改exttrail或者rmttrail的write checkpoint

GGSCI (node1) 47> ADD EXTTRAIL /opt/ggs/dirdat/r1/ex,SEQNO 3, RBA 51132, EXTRACT ext_r1 
EXTTRAIL added.

7. 驗證checkpoint是否修改爲功(使用showch,略)

8.從新啓動extract(略)