Как ведет себя standby после failover primary database

Пришлось тут на днях выполнить failover на один из standby. Были опасения, как себя поведет второй standby после такого. Оказалось, ничего страшного, даже процесс MRP был перезапущен автоматически.

Ниже фрагмент alert.log:

Media Recovery Waiting for thread 1 sequence 17950
Tue Apr 08 12:29:49 2014
RFS[1]: Assigned to RFS process 32052
RFS[1]: Opened log for thread 1 sequence 25 dbid 965167768 branch 844331483
A new recovery destination branch has been registered
RFS[1]: Standby in the future of new recovery destinationBranch(resetlogs_id) 844331483
Incomplete Recovery SCN: 17347307
Resetlogs SCN: 17347308
Standby Became Primary SCN: 17347305
RFS[1]: New Archival REDO Branch(resetlogs_id): 844331483 Prior: 833198555
RFS[1]: Archival Activation ID: 0x39a01d0e Current: 0x39871096
RFS[1]: Effect of primary database OPEN RESETLOGS
RFS[1]: Managed Standby Recovery process is active
RFS[1]: Incarnation entry added for Branch(resetlogs_id): 844331483 (IDM1)
Tue Apr 08 12:29:50 2014
Setting recovery target incarnation to 3
Archived Log entry 17945 added for thread 1 sequence 25 rlc 844331483 ID 0x39a01d0e dest 3:
Tue Apr 08 12:29:52 2014
MRP0: Incarnation has changed! Retry recovery...
Errors in file /opt/oracle/base/diag/rdbms/idm/IDM1/trace/IDM1_pr00_30363.trc:
ORA-19906: recovery target incarnation changed during recovery
Recovery interrupted!
Tue Apr 08 12:29:52 2014
started logmerger process
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 32 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Tue Apr 08 12:29:53 2014
Media Recovery Waiting for thread 1 sequence 1
Fetching gap sequence in thread 1, gap sequence 1-24
Tue Apr 08 12:30:54 2014

В логе. Второй standby на всякий случай был выключен в момент failover. Спустя некоторое время его включили обратно, primary передал на него очередной журнал (25-й по счету). Standby увидел, что в в нем новая инкарнация, добавил её в controlfile, переключился на неё, рестартовал процесс mrp, и запросил по механизму FAL пропущеные 24 лога. И все это автоматически 🙂

После появления бывшего primary в online удалось сделать из него standby и заставить накатывать логи уже нового primary.

Хронология событий примерно следующая.

1. Новая инкарнация началась с scn 17347307, список инкарнаций можно увидеть запросом (на новом primary)


SQL> select INCARNATION#, RESETLOGS_CHANGE#, PRIOR_RESETLOGS_CHANGE#, STATUS from v$database_incarnation;

INCARNATION# RESETLOGS_CHANGE# PRIOR_RESETLOGS_CHANGE# STATUS
------------ ----------------- ----------------------- ---------------------
1 1 0 PARENT
2 925702 1 PARENT
3 17347308 925702 CURRENT

2. Восстановили бывший primary. Здесь важно было сделать все аккуратно и стартовать clusterware так, чтобы он не поднял автоматом БД. После чего превратили его в standby:


SQL> alter database convert to physical standby;

3. С бывшим primary повезло — он начал контрольную точку, заархивировал журнал, и после этого упал. Так что после восстановления в v$datafile_header мы увидели:


SQL> select file#, CHECKPOINT_CHANGE#, RESETLOGS_CHANGE# from v$datafile_header;

FILE# CHECKPOINT_CHANGE# RESETLOGS_CHANGE#
---------- ------------------ -----------------
1 17346537 925702
2 17346537 925702
3 17346537 925702
4 17346537 925702
5 17346537 925702
6 17346537 925702
7 17346537 925702
8 17346537 925702
9 17346537 925702
10 17346537 925702
11 17346537 925702
12 17346537 925702
13 17346537 925702

Последняя контрольная точка


SELECT RTCKP_SCN, RTCKP_TIM FROM X$KCCRT;

RTCKP_SCN RTCKP_TIM
------------------------------------------------ ------------------------------------------------------------
17346537 04/08/2014 00:41:54

Текущая контрольная точка


SQL> SELECT CPODS,CPODT,CPSDR_SEQ FROM X$KCCCP where cpods>0;

CPODS CPODT CPSDR_SEQ
------------------------------------------------ ------------------------------------------------------------ ----------
17347304 04/08/2014 00:51:56 17949

И последний журнал


select sequence#, first_change#, first_time, next_change#, next_time from v$archived_log
2 where sequence# = (select max(sequence#) from v$archived_log where resetlogs_change# = 925702);

SEQUENCE# FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ------------- ----------------------- ------------ -----------------------
17949 17346537 08 apr 2014 00:41 17347307 08 apr 2014 00:51

4. Накатили последний журнал на бывший primary


SQL> recover standby database;

5. Посмотрели еще раз на заголовки файлов:


SQL> select file#, CHECKPOINT_CHANGE#, RESETLOGS_CHANGE# from v$datafile_header;

FILE# CHECKPOINT_CHANGE# RESETLOGS_CHANGE#
---------- ------------------ -----------------
1 17347307 925702
2 17347307 925702
3 17347307 925702
4 17347307 925702
5 17347307 925702
6 17347307 925702
7 17347307 925702
8 17347307 925702
9 17347307 925702
10 17347307 925702
11 17347307 925702
12 17347307 925702
13 17347307 925702

6. Руками передали один из архивных журналов и зарегистрировали его в управляющем файле


rman> catalog archivelog '/opt/oracle/thread_1_seq_1.695.844332149';

7. После чего в списке инкарнаций БД увидели


SQL> select INCARNATION#, RESETLOGS_CHANGE#, PRIOR_RESETLOGS_CHANGE#, STATUS from v$database_incarnation;

INCARNATION# RESETLOGS_CHANGE# PRIOR_RESETLOGS_CHANGE# STATUS
------------ ----------------- ----------------------- ---------------------
1 1 0 PARENT
2 925702 1 CURRENT
3 17347308 925702 ORPHAN

К сожалению, автоматически заставить БД нереключиться на новую инкарнацию, как это произошло с остальными standby БД, не удалось. Экземпляр спокойно принимал новые архивных журналы, запрашивал механизмом FAL пропуски, но накатывать их отказывался.

8. Руками переключили БД на новую инкарнацию


rman> reset database to incarnation 3;

после чего стартовали MRP, в течение часа догнали новый primary, и получили нормальный standby

9. Дополнительно проверили, что во время инкрементальной контрольной точки в файлы данных не записалось ничего «лишнего»:


rman> validate database check logical;

List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1 OK 0 13718 111367 17537365
File Name: +DATA/idm/datafile/system.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 75029
Index 0 14704
Other 0 7909

В принципе, полезно было бы прогнать эту команду в пункте 3, посмотреть на High SCN в файлах данных, но это hint на будущее 🙂

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s