통상 HA 구성 완료 후 데이터 동기화 여부를 확인하기 위해 master node에 접속하여 데이터를 추가해보고 slave node에 접속하여 데이터가 복제 되었는지 확인하는 절차를 거친다.
이때 데이터 동기화가 곧바로 이뤄지지 않고 10초 이상 지연되는 현상이 발견되었다.
문제점 확인을 위해 아래와 같은 절차로 확인을 진행하였다.
1. HA 구성 상태 및 관련 process 상태를 확인을 위해 cubrid hb status를 수행해보았으나 특별한 문제점은 보이지 않았고 process도 모두 구동되어 있었다.
2. 혹시 copylogdb, applylogdb process가 재 구동 되고 있는지 각 process의 PID 변경 여부를 확인했으나 이상이 없었다.
3. 다음으로 slave node에서 cubrid applyinfo를 사용하여 복제로그 복사 및 반영 상태를 확인 해보았더니 아래와 같이 결과 중 copied active info 부분의 HA server state가 dead 상태였다. (HA server state는 master node의 데이터베이스 서버 프로세스의 상태를 나타내는 것인데 dead는 죽었거나 copylogdb 프로세스와 통신에 실패하였을 경우에 나타난다.)
[ssihil@newTest3 ~]$ cubrid applyinfo -L /home/ssihil/CUBRID/databases/testdb_newTest1/ -r newTest1 -a testdb *** Applied Info. *** Committed page : 28279 | 15544 Insert count : 1004 Update count : 1005 Delete count : 3 Schema count : 11 Commit count : 114 Fail count : 1
*** Copied Active Info. *** DB name : testdb DB creation time : 11:05:15.000 AM 11/26/2012 (1353895515) EOF LSA : 28279 | 15544 Append LSA : 28279 | 15544 HA server state : dead
*** Active Info. *** DB name : testdb DB creation time : 11:05:15.000 AM 11/26/2012 (1353895515) EOF LSA : 28279 | 16112 Append LSA : 28279 | 16112 HA server state : active |
Master node의 데이터베이스 서버 프로세스가 정상적으로 구동되어 있는 상태인데 dead 상태이므로 통신에 문제가 있는 것으로 판단되어 cubrid applyinfo를 반복해서 수행해보자 Copied Active Info의 HA server state가 active로 바뀌었다가 다시 dead로 바뀌는 현상이 확인되었다.
4. 추가적으로 master node에서 cubrid killtran을 반복 실행하여 보니 copylogdb process가 사라졌다 나타나는 현상이 발견되었다. Process id가 변경되지 않는 것으로 보아 process가 재 구동되는 것은 아니고 데이터베이스 서버 프로세스와 접속이 끊어 지는 것으로 확인되었다.
[ssihil@newTest1 ~]$ cubrid killtran testdb@localhost Tran index User name Host name Process id Program name ------------------------------------------------------------------------------- 2(+) dba newTest1 5151 applylogdb 3(+) dba newTest3 23979 copylogdb ------------------------------------------------------------------------------- [ssihil@newTest1 ~]$ cubrid killtran testdb@localhost Tran index User name Host name Process id Program name ------------------------------------------------------------------------------- 2(+) dba newTest1 5151 applylogdb ------------------------------------------------------------------------------- … [ssihil@newTest3 ~]$ cubrid killtran testdb@localhost Tran index User name Host name Process id Program name ------------------------------------------------------------------------------- 1(+) dba newTest1 23979 copylogdb 2(+) dba newTest3 5151 applylogdb ------------------------------------------------------------------------------- |
CUBRID는 서버 프로세스와 클라이언트 프로세스(copylogdb, applylogdb, cub_cas 등)가 접속이 이뤄진 후 네트워크를 통해 데이터를 기다리는 중 오랫동안 응답을 받지 못하면 상대방이 정상 동작하는지 확인하기 위해 ECHO(7) 포트에 주기적으로 접속하여 각 프로세스가 정상 동작하는지 확인한다. 이때 접속에 실패하면 기존에 연결된 접속을 강제 종료한다.
5. ECHO 포트가 방화벽 설정으로 막혀 있는지를 확인 해보기 위해 telnet으로 master node의 ECHO 포트에 접속하여 보았더니 아래와 같이 접속 시도 중 상태로 멈춰있었다.
[ssihil@newTest3 testdb]$ telnet newTest1 7 Trying 192.168.0.231...
|
포트가 열려 있는 정상 적인 경우에는 아래와 같은 결과가 나타난다.
[ssihil@newTest3 testdb]$ telnet newTest1 7 Trying 192.168.0.231... telnet: connect to address 192.168.0.231: Connection refused telnet: Unable to connect to remote host: Connection refused |
6. 각 node에서 iptables --list를 수행하여 방화벽 설정 상태를 확인하였더니 아래와 같이 ECHO 포트가 막혀 있는 것을 확인할 수 있었다.
[root@newTest1 ~]# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination DROP tcp -- anywhere anywhere tcp dpt:echo
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination |
7. 각 node에서 아래와 같이 방화벽 설정을 해제 한 후 cubrid applyinfo, cubrid killtran을 수행하자 정상적으로 수행됨이 확인되었고 데이터를 입력하자 slave node에 곧바로 반영됨이 확인되었다. (iptables 사용법은 큐브리드 홈페이지 개발자 > Documents > 튜토리얼 > CUBRID 사용 포트와 iptables(방화벽) 설정 참고)
[root@newTest1 ~]# iptables –D INPUT 1 [root@newTest1 ~]# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination |
참고로 CUBRID 2008 R4.3 버전에는 check_peer_alive 파라미터가 추가 되었고 none로 설정하면 위와 같이 방화벽 정책에 의해 ECHO 포트가 막혀있는 경우 문제를 회피할 수 있다.(자세한 사항은 CUBRID 온라인 매뉴얼(8.4.3) > 시스템 설정 > 데이터베이스 서버 설정 > 접속 관련 파라미터 참고)