기타

HA 환경 구성 시 데이터 복제 지연이 발생하는 경우 ECHO(7) port를 확인하자.

by 손승일 posted Nov 29, 2012

통상 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 statemaster 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 InfoHA server stateactive로 바뀌었다가 다시 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) > 시스템 설정 > 데이터베이스 서버 설정 > 접속 관련 파라미터 참고)

 


Articles

1 2 3 4