* 질문 등록 시 다음의 내용을 꼭 기입하여 주세요.
|
|
Oracle Linux 7.9 |
|
|
10.2.5.8886 |
|
|
[도움말]-[버전정보] 확인 |
|
|
java, php, odbc 등 입력 |
* CUBRID 응용 오류, SQL 오류 또는 SQL 튜닝 관련된 문의는 반드시 다음의 내용을 추가해 주세요. 비밀글이나 비밀 댓글도 가능합니다.
* 저희가 상황을 이해하고, 재현이 가능해야 알 수 있는 문제들이 많습니다. 가능한 정보/정황들을 부탁합니다.
| 에러 내용 및 재현 방법 | 재현 가능한 Source와 SQL |
| 관련 테이블(인덱스, 키정보 포함) 정보 | CUBRID 홈 디렉토리 아래 log 디렉토리 압축 |
-------------- 아래에 질문 사항을 기입해 주세요. ------------------------------------------------------------------------
HA 구성 중 슬레이브 재구축 관련하여 답변을 주셨는데 이해가 정확히 되지 않아 다음과 같이 정리 및 테스트를 진행했습니다.
일단 이전과는 다르게 슬레이브 노드에서 HA가 정상적으로 기동되었으며, HA도 정상적으로 동작하는것 같습니다.
틀린 부분이나 제가 잘못 이해하고 있는 부분이 있다면 답변 부탁 드립니다.
================================================================================
** 구성 환경
마스터(urp1) - 슬레이브(urp2) - 레플리카(urp3)
** 시나리오 (서비스 운영 중 슬레이브 재구축)
- 마스터:슬레이브:레플리카가 1:1:1로 구축된 환경에서 슬레이브 노드의 데이터에 이상이 발생했다고 가정
- 마스터 노드로부터 데이터를 완전히 새로 구축
- 현재 마스터 노드의 DB는 운영중인 상태
** 작업 순서
1) 슬레이브 노드의 HA 및 서비스 중지
[cubrid@urp2 ~]$ cubrid heartbeat stop
[cubrid@urp2 ~]$ cubrid service stop
2) 슬레이브 노드의 데이터베이스 볼륨, 복제 로그 삭제 (노드 B)
[cubrid@urp2 ~]$ cd $CUBRID_DATABASES
[cubrid@urp2 databases]$ rm testdb/*
[cubrid@urp2 databases]$ rm testdb/log/*
[cubrid@urp2 databases]$ rm -rf testdb_urp1
3) 마스터 노드 및 레플리카 노드에서 슬레이브 노드의 로그 복제 중지
[cubrid@urp1 ~]$ cubrid heartbeat copylogdb stop testdb urp2
[cubrid@urp1 ~]$ cubrid heartbeat applylogdb stop testdb urp2
[cubrid@urp3 ~]$ cubrid heartbeat copylogdb stop testdb urp2
[cubrid@urp3 ~]$ cubrid heartbeat applylogdb stop testdb urp2
4) 마스터 노드 및 레플리카 노드에서 슬레이브 노드에 대한 복제 로그 삭제
[cubrid@urp1 ~]$ rm -rf $CUBRID_DATABASES/testdb_urp2
[cubrid@urp3 ~]$ rm -rf $CUBRID_DATABASES/testdb_urp2
5) 슬레이브 노드에 대한 복제 정보 제거 (레플리카 노드에서 수행)
[cubrid@urp3 ~]$ csql -u dba testdb@localhost --sysadm --write-on-standby
sysadm> DELETE
sysadm> FROM db_ha_apply_info
sysadm> WHERE copied_log_path = '/app/cubrid/CUBRID/databases/testdb_urp2';
6) 마스터 노드에서 데이터베이스 백업 및 슬레이브 노드로 백업 파일 전송
[cubrid@urp1 tmp]$ cubrid backupdb -z -C -D . -o full_bk.log testdb@localhost
[cubrid@urp1 tmp]$ scp testdb_bk0v000 cubrid@urp2:~/tmp
7) 슬레이브 노드에서 복구
[cubrid@urp2 tmp]$ cubrid restoredb -B . -o restore.log testdb
8) 마스터 노드의 활성 로그(Active log)를 슬레이브 노드에 복사 (슬레이브 노드에서 수행)
[cubrid@urp2 tmp]$ cub_master
[cubrid@urp2 tmp]$ cubrid heartbeat copylogdb start testdb urp1
9) copylogdb 및 cub_master 프로세스 중지(슬레이브 노드에서 수행)
[cubrid@urp2 testdb_urp1]$ cubrid heartbeat copylogdb stop testdb urp1
[cubrid@urp2 testdb_urp1]$ cubrid service stop
10) 슬레이브 노드에 데이터베이스 복구 이후 필요한 로그 파일 복사 (슬레이브 노드에서 수행)
[cubrid@urp2 testdb_urp1]$ scp cubrid@urp1:$CUBRID_DATABASES/testdb/log/testdb_lgar0* .
11) 슬레이브 노드에서 HA 구동
[cubrid@urp2 testdb_urp1]$ cubrid heartbeat start
12) 마스터 노드 및 레플리카 노드에서 copylogdb, applylogdb 프로세스 기동
[cubrid@urp1 tmp]$ cubrid heartbeat copylogdb start testdb urp2
[cubrid@urp1 tmp]$ cubrid heartbeat applylogdb start testdb urp2
[cubrid@urp3 tmp]$ cubrid heartbeat copylogdb start testdb urp2
[cubrid@urp3 tmp]$ cubrid heartbeat applylogdb start testdb urp2
================================================================================
그리고 이전 글에서 마지막 답변으로 다음과 같이 답변을 주셨는데요,
(1) 지적하신대로 매뉴얼의 slave db에서 db_ha_apply_info 를 삭제하는 부분이 순서가 잘 못되었네요.
master db의 백업을 가지고 slave에서 복구 후에 삭제하는 것이 맞습니다. 이 부분의 매뉴얼은 수정하도록 하겠습니다.
매뉴얼 오류에 대해 보고해주셔서 감사합니다.
--> 해당 내용은 마스터 노드의 서비스 중지 후 재구성할 때 진행하는게 맞는건가요?
(2) 현재 설명 그림의 재구성 방법은 master db의 서비스를 멈추지 않고 재구성하는 방법의 설명입니다.
백업 후에도 insert/delete/update.가 발생할 수 있어, 백업시의 최종 로그 정보를 기억해두었다가 slave db 재구성시 db_ha_apply_info에 master 복제에 대한 정보를 기입하여 백업 시점이후의 변경된 정보부터 복제를 하기 위함입니다.
--> 그러면 굳이 마스터 노드쪽의 db_ha_apply_info 테이블의 레코드를 삭제하지 않고 백업 수행 후,
슬레이브 노드에서 DB 재구축 후 활성 로그 및 보관 로그만 전달 한 다음에 HA 기동하면 될까요?
(위 작업 단계에서 7번, 8번)
