SAP HANA 보조 시스템 시간 여행__SAP HANA Secondary Time Travel

감귤은탱귤·2024년 10월 30일

-sr_timetravel BC HANA SAP Secondary Time Travel System Replication Time Travel hdbnsutil logreplay snapshot 시간 여행

SAP HANA - 작업 매뉴얼

목록 보기

8/8

SAP 운영 중에 가끔 실수 또는 착각으로 운영 데이터가 삭제되는 일이 아주아주 드물게 생길 때가 있다.
특히 삭제된 데이터가 해당 시스템에서만 유지보수하는 마스터 데이터라면 복구가 필요한데, 이걸 복구하는 과정도 만만치가 않다.

그나마 개발, 품질 시스템에서 이러한 일이 일어난다면 그래도 영향도가 적지만, 운영 시스템에서는 이야기가 달라진다.

SAP 시스템에 테이블 로깅 파라미터(rec/client)가 활성화되어있고, 문제의 테이블 또한 로깅이 활성화되어 있다면, 그래도 삭제된 데이터를 찾아 복구가 가능하지만 이러한 경우가 아니라면, 사실상 시스템 전체를 Recovry 하여 삭제된 데이터를 찾아야 한다. (테이블 단위로는 Recovery 가 안되기 때문)

시스템 전체를 Recovry 하는 일도 쉽지는 않다.
그래도 중요한 데이터가 삭제된걸 빠른 시간 안에 인지를 했다면 백업본이 남아있겠지만, 인지가 많이 늦었다면 백업본을 찾기가 쉽지 않다.

다행히 백업본이 있어 Recovry 를 시작한다고 해도, 운영 시스템과 동일한 리소스의 서버가 있어야 하는데, 대부분의 경우에는 사실상 선택지가 품질 시스템밖에 없기에 여러 작업이 수반된다.

이러한 이유로 삭제된 데이터를 복구하기는 매우 힘든 작업인데,
우연히 SAP Help Portal 문서를 보던 중, 위와 관련된 재미있는 내용이 있어서 소개하려고 한다.

1. Secondary (System) Time Travel

❗❗ SAP HANA 2.0 SPS 03 이상 버전에서/ 기본 시스템과 보조 시스템의 System Replication 의 Operation Mode 가 logreplay, logreplay_readaccess 일 경우에만 Time Travel 이 가능하다.

기본 DB시스템(Primary, Active) 과 System Replication 상태인 보조 DB시스템(Secondary, Standby) 을 사용하여 삭제된 데이터에 대해 빠르게 엑세스 할 수 있다.

보조 시스템에서의 Time Travel 은 스냅샷과 로그 복원(Replay) 를 통해 사용자가 원하는 시점으로 DB 를 복구할 수 있다.

이러한 Time Travel 은 Replication Modes - SYNC(Full Sync Option) 모드라면 안전하게 사용할 수 있으며, 보조 시스템은 Time Travel 동안 기본 시스템과의 연결을 유지하며, 이로인해 기본 시스템이 정지되는 위험은 없다고 SAP 공식 문서 에서 설명한다.

Time Travel 중에도 보조 시스템(Secondary) 으로 로그는 계속 전달되나 복원(Replay) 은 되지 않는다.
만약 Operation Mode 가 logreplay_readaccess 일 경우에는 Replication 을 유지하면서 Time Travel (Secondary Time Travel While Replication Continues) 이 가능해진다.
(단, logreplay_readaccess 는 별도의 라이선스가 필요하다.)

2. Time Travel 파라미터 설정

Secondary (System) Time Travel 을 위해서는 보조 시스템의 global.ini 에서 파라미터 설정이 필요하다.

파라미터가 올바르게 설정되어있고 Time Travel 기능이 활성 상태인지는 보조 시스템에서 hdbcons 명령어를 사용하여 확인할 수 있다.
해당 명령어로 출력되는 값은 ms 단위이다.
hdbcons 'replication info' | grep timetravel

아래 모든 파라미터는 보조 시스템에서 설정한다.

Time Travel 설정을 하면, 당연히 보조 시스템에서의 로그/ 데이터의 크기가 증가한다.
따라서, 로그/ 디스크가 가득 차는 상황을 예방하기 위해, 적절한 파라미터 설정이 필요하다. 시스템의 리소스와 가용량을 확인하여 단계적으로 설정하기를 추천한다.

2-1. timetravel_snapshot_creation_interval

global.ini -> [system_replication] -> timetravel_snapshot_creation_interval

Secondary Time Travel 을 위한 Snapshot 의 간격을 설정할 수 있다.
단위는 분이며, Default 값은 1440 이다.

2-2. timetravel_max_retention_time

global.ini -> [system_replication] -> timetravel_max_retention_time

Secondary Time Travel Snapshot 이 보관되는 기간이다.
설정된 보관 기간이 지난 Snapshot 은 자동으로 삭제된다.
단위는 분이며, Default 값은 0 이다.

❗❗ 해당 파라미터의 값이 0이라면, Secondary Time Travel 기능을 비활성화 한다.
따라서, 해당 파라미터 값을 1 이상으로 설정하여 활성화한 순간부터 Time Travle 이 가능하며, Time Travel Snapshot 이 보관된다.

2-3. timetravel_call_takeover_hooks

global.ini -> [system_replication] -> timetravel_call_takeover_hooks

Time Travel 중에 TakeOver Hook 을 호출하는지에 대한 여부이다.
Default 값은 false 이다.

2-4. timetravel_logreplay_mode

global.ini -> [system_replication] -> timetravel_logreplay_mode

Time Travel 시, 보조 시스템에서 로그 복원(Replay) 이 실행되는 방법을 정의한다.
auto / manual 중 선택할 수 있으며, Default 값은 auto 이다.

auto : Time Travel 수행 지점으로 가능한 가장 최신 로그 위치까지 자동 복원
manual : 로그 복원을 수동으로 트리거한다. -sr_recoveruntil 옵션으로 지정된 타임스탬프까지 복원된다.

3. Time Travel 가능 지점 확인

위와 같이 올바른 파라미터 설정과 함께 Time Travel Snapshot 이 있다면, 해당 지점으로 시간 여행이 가능하다.

Time Travel 이 가능한 지점, 즉 Time Travel Snapshot 은 다음 명령어로 확인이 가능하다.

hdbnsutil -sr_timetravel --printRange

STARTTIME : Time Travel 을 실행할 수 있는 가장 예전 시점, 해당 시간 이후부터 시간 여행이 가능하다. (dd.mm.yyyy-hh.mm.ss 형식)
ENDTIME : Time Travel 을 실행할 수 있는 마지막 시점

또는 모니터링 뷰 SYS.M_SYSTEM_REPLICATION_TIMETRAVEL 를 통해서도 확인 가능하다.

4. Secondary Time Travel 수행

4-1. 기본 Secondary Time Travel

이제 본격적으로 Time Travel 을 수행한다.

Time Travel 종료 및 재동기화 때, System Replication 정보가 필요하니, Time Travel 수행 전, 해당 정보를 미리 기록해두도록 하자.

먼저 보조 시스템(Secondary) 을 중지한다.
HDB stop
보조 시스템에서 Time Travel 명령어를 수행한다.
hdbnsutil -sr_timetravel --startTime=<start_time> [--callTakeoverHooks=on|off] [--comment="코멘트"]

<start_time> 은 UTC 타임스탬프 형식인 "dd.mm.yyyy-hh24.mm.ss" 로 지정.
또한, callTakeoverHooks 나 comment 는 생략해도 무방하다.
보조 시스템을 다시 시작한다.
HDB Start

보조 시스템은 이제 지정된 시점(Time Travel 명령어에서 설정한 시작시간) 에서 온라인 모드로 전환된다.

이제 보조 시스템 DB 는 Time Travel 한 시점의 데이터 지속성을 가지게 되며, 데이터에 대한 조회가 가능하다.

4-2. Secondary Time Travel While Replication Continues

SAP Help Portal 문서에서는 해당 기능은 보조 시스템의 로그 복원을 의도적으로 지연시켜, 기본-보조 시스템이 Replication 상태에 있음에도 보조 시스템에서 삭제된 데이터를 읽을 수 있다고 설명한다.

System Replication 의 Operation Mode 가 logreplay_readaccess 일 경우, 보조 시스템(Secondary) 에서 Replication 을 유지한 상태로 Time Travel 이 가능하다.

기본 Time Travel 명령어에서 --startMode 옵션을 추가하면 된다.
hdbnsutil -sr_timetravel --startTime=<start_time> --startMode=replicate

여기서 timetravel_logreplay_mode 파라미터 설정이 manual 이라면, -sr_recoveruntil 옵션을 사용해서 수동으로 로그 복원을 수행할 수 있다.
hdbnsutil -sr_recoveruntil {endTime=<timestamp>|max} [--nowait]

endTime 에서 max 는, 사용 가능한 가장 최신 시점까지 로그를 복원한다.
--nowait 옵션은 생략 가능하며, 추가하면 명령을 동기적으로 수행할 수 있다.

manual 로그 복원을 중지하려면, timetravel_logreplay_mode 파라미터를 다시 auto 로 설정하거나, 다음 명령어를 사용하면 된다.
hdbnsutil -sr_replaymode --mode=auto

5. Time Travel 종료 및 재동기화

아래 재동기화 작업은 기본 Time Travel 시에만 사용한다.
Secondary Time Travel While Replication Continues 의 경우, 의도적으로 보조 시스템의 로그 복원을 지연한 경우이기 때문이다.

보조 시스템에서 Time Travel 로 필요한 데이터를 확보했다면, 이제 보조 시스템을 기본 시스템과 다시 동기화(resync) 해야 한다.

보조 시스템을 중지한다.
HDB stop

보조 시스템에서 System Replication 을 다시 활성화한다.

hdbnsutil -sr_register 
--name=<Secondary Site Name>
--remoteHost=<Primary DB Hostname> 
--remoteInstance=<Primary Instance number> 
--replicationMode=[sync|syncmem|async] 
--operationMode=[delta_datashipping|logreplay|logreplay_readaccess]