Cubrid HA - 2 (slave server setting)

 큐브리드 HA란, cubrid HA 초기세팅, cubrid master 서버 설정이 궁금하면:

https://seul96.tistory.com/172?category=843617

Cubrid HA - 1 (HA란, 초기세팅, master 서버 설정)

 

1.1.1.  nodeA 복제

지금까지 설정한 nodeA를 복제 복제하기 전에 스냅샷 추천

먼저 가상머신을 종료

Machien - >Clone

 

cent6_cubrid10.1_nodeB

 

 

복제한 nodeB로 접속

nodeB의 HOSTNAME을 nodeB로 변경해주세요.

[root@nodeA ~]# vi /etc/sysconfig/network

Ip 주소는 169.254.173.253로 설정

vi /etc/sysconfig/network-script/ifcfg-eth1 --없으면 생성

DEVICE=eth1  ONBOOT=yes  IPADDR=169.254.173.253  NETMASK=255.255.255.0  BOOTPROTO=static  NM_CONTROLLED=no

reboot로 재시작

hostname으로 ping이 잘 되는지 확인

ping이 안되면 master-slave끼리 주고 받을 수 없기 때문에 master서버가 active 서버로 전환 안되는 문제가 발생할 수 있음. 꼭 ping을 확인하고 넘어가야함.

 

1.2.  CUBRID HA 시작 및 확인

1.2.1.  CUBRID HA 시작

CUBRID HA 그룹 내의 각 노드에서 cubrid heartbeat start 를 수행한다. cubrid heartbeat start 를 가장 먼저 수행한 노드가 마스터 노드가 되므로 유의해야 한다. 이하의 예에서 마스터 노드의 호스트 이름은 nodeA, 슬레이브 노드의 호스트 이름은 nodeB라고 가정한다.

[cub_user@nodeA rpm]$ cubrid heartbeat start      --먼저

[cub_user@nodeB rpm]$ cubrid heartbeat start      --나중

 

서버의 상태 확인

[cub_user@nodeA rpm]$ cubrid heartbeat status

nodeA는 active로 동작

nodeB는 standby로 동작

[cub_user@nodeA rpm]$ cubrid changemode testdb@localhost

 

1.2.2.  CUBRID HA 동작 여부 확인

마스터 노드의 액티브 서버에서 쓰기를 수행한 후 슬레이브 노드의 스탠바이 서버에 정상적으로 반영되었는지 확인한다. HA 환경에서 CSQL 인터프리터로 각 노드에 접속하려면, 데이터베이스 이름 뒤에 접속 대상 호스트 이름을 반드시 지정해야 한다("@<호스트 이름>"). 호스트 이름을 localhost로 지정하면, 로컬 노드에 접속하게 된다.

복제가 정상적으로 수행되기 위해서는 테이블을 생성할 때 기본키(primary key)가 반드시 존재해야 한다는 점을 주의한다 => 정리하면 기존에는 csql -u dba testdb로 되었지만 이제는 csql -u dba testdb@localhost로 접속해야한다.

 

[cub_user@nodeA rpm]$ csql -u dba testdb@localhost -c "create table abc(a int, b int, c int, primary key(a));"

Execute OK. (0.068947 sec) Committed.

[cub_user@nodeA rpm]$ csql -u dba testdb@localhost -c "insert into abc values (1,1,1);"

1 row affected. (0.001228 sec) Committed.

 

2. Cubrid HA 테스트

혼자 궁금해서 이것저것 해본 테스트...★

2.1.  DB 복제 테스트

Master 서버인 nodeA에서 abc 테이블을 만들고 slave 서버인 nodeB에서 select 하면 database가 복제된 것을 확인할 수 있다. (위에 확인)

 

2.2.  Failover 테스트

Master가 종료되면 slave가 master가 되는지 테스트

master 서버를 강제 종료 시켜주기

shutdown -h now

기존에 slave 서버에 가서 cubrid changemode testdb@localhost로 상태를 확인하면

Slave -> to-be-active -> active 가 되는 것을 확인 할 수 있다.

 

2.3.  slave 종료 후 master에서 db생성시 slave에 db 저장 여부.

cubrid heartbeat stop 명령어로 slave인 nodeA를 stop 시킨다.

active 서버인 nodeB로 와서 table을 생성한다. (현재 slave heartbeat stop된 상태)

다시 slave를 키면 slave가 stop된 시간에 master에 저장된 db를 slave에서도 확인할 수 있다.

wow amazing!

 

 

2.4.  master -> slave -> master 전환 확인

slave였던 nodeB가 active가 되었는데 현재 active인 nodeB를 shutdown하면 slave였던 nodeA가 다시 master가 되는 것을 확인.

3. Cubrid HA 구동 및 모니터링 (홈페이지 참조)

3.1.  Cubrid heartbeat 유틸리티

cubrid heartbeat 명령은 줄여서 cubrid hb로도 실행할 수 있다.

3.1.1.  start

해당 노드의 CUBRID HA 기능을 활성화하고 구성 프로세스(데이터베이스 서버 프로세스, 복제 로그 복사 프로세스, 복제 로그 반영 프로세스)를 모두 구동한다. cubrid heartbeat start를 실행하는 순서에 따라 마스터 노드와 슬레이브 노드가 결정되므로, 순서를 주의

사용법은 다음과 같다.

$ cubrid heartbeat start

 

HA 모드로 설정된 데이터베이스 서버 프로세스는 cubrid server start 명령으로 시작할 수 없다.

노드 내에서 특정 데이터베이스의 HA 구성 프로세스들(데이터베이스 서버 프로세스, 복제 로그 복사 프로세스, 복제 로그 반영 프로세스)만 구동하려면 명령의 마지막에 데이터베이스 이름을 지정한다. 예를 들어, 데이터베이스 testdb만 구동하려면 다음 명령을 사용한다.

$ cubrid heartbeat start testdb

 

3.1.2.  stop

해당 노드의 CUBRID HA 기능을 비활성화하고 구성 프로세스(데이터베이스 서버 프로세스, 복제 로그 복사 프로세스, 복제 로그 반영 프로세스)를 모두 종료한다. 이 명령을 실행한 노드의 HA 기능은 종료되고 HA 구성에 있는 다음 순위의 슬레이브 노드로 failover가 일어난다.

사용법은 다음과 같다.

$ cubrid heartbeat stop

HA 모드로 설정된 데이터베이스 서버 프로세스는 cubrid server stop 명령으로 정지할 수 없다.

CUBRID HA 기능을 즉각 비활성화하려면 "cubrid heartbeat stop" 명령에 -i 옵션을 추가한다. 이 옵션은 DB 서버 프로세스가 비정상적인 동작을 수행하고 있어 빠른 절체가 필요한 경우 사용한다.

$ cubrid heartbeat stop -i

or

$cubrid heartbeat stop --immediately

 

3.1.3.  deregister

CUBRID HA 구성 프로세스인 applylogdb 혹은 copylogdb를 종료한다. deregister 실행 시 프로세스 ID로 종료할 프로세스를 지정한다. 마스터 노드를 재구성하는 등의 작업을 위해 HA 로그 복제(copylogdb) 또는 복제 로그 반영(applylogdb)을 일시 정지하기 위한 용도로 사용하며, 이후 HA 기능을 재개하려면 cub_admin copylogdb와 cub_admin applylogdb를 수동으로 실행해야 한다.

운영 상 필요할 때에만 사용해야 하며 일반적으로는 사용을 권장하지 않는다.

사용법은 다음과 같다.

$ cubrid heartbeat deregister <process-id>

 

opylogdb를 deregister한 이후 재실행하는 예는 다음과 같다. -L 옵션은 복제 로그가 저장될 위치이며, -m 옵션은 복제 로그를 저장하는 모드로서 cubrid_ha.conf의 ha_copy_sync_mode 파라미터와 같은 역할을 한다. 옵션 값은 cubrid_ha.conf에서 설정한 것과 동일하게 지정한다.

$ cub_admin copylogdb -L /home/cubrid/DB/testdb_nodeA -m async testdb@node-hostname &

applylogdb를 deregister한 이후 재실행하는 예는 다음과 같다. -L 옵션은 저장된 트랜잭션 로그를 읽을 위치이며, --max_mem-size는 applylogdb 프로세스가 사용할 최대 메모리 크기로서 cubrid_ha.conf의 ha_apply_max_mem_size 파라미터와 같은 역할을 한다. 옵션 값은 cubrid_ha.conf에서 설정한 것과 동일하게 지정한다.

$ cub_admin applylogdb -L /home/cubrid/DB/testdb_nodeA --max-mem-size=500 testdb@localhost &

status

CUBRID HA 그룹 정보와 CUBRID HA 구성 요소의 정보를 확인할 수 있다. 사용법은 다음과 같다.

$ cubrid heartbeat status

@ cubrid heartbeat status

 

 HA-Node Info (current nodeB, state slave)

   Node nodeB (priority 2, state slave)

   Node nodeA (priority 1, state master)

 

 

 HA-Process Info (master 2143, state slave)

   Applylogdb testdb@localhost:/home/cubrid/DB/testdb_nodeB (pid 2510, state registered)

   Copylogdb testdb@nodeA:/home/cubrid/DB/testdb_nodeA (pid 2505, state registered)

   Server testdb (pid 2393, state registered)

 

4. Cubrid HA 설치 시 에러

4.1.  usage: cubrid [OPTION] database-name database-locale

뒤에 database-locale을 설정하지 않아서 생기는 에러 9.2 이후부터 database-locale을 설정해줘야 db를 생성할 수 있다.

[에러해결]

ð  cubrid createdb -L ./log testdb  en_US.iso88591 로 해서 해결

 

4.2.  Locale initialization: invalid value ko_KR_utf8 for charset.

Ko_KR_utf8이 없어서 생기는 에러로 있는 database-locale로 생성해야 한다.

[에러해결]

ð  cubrid createdb -L ./log testdb  en_US.iso88591 로 해서 해결

 

4.3.  cubrid server start: fail

Database 시작 시 실패

[에러해결]

ð  /etc/hosts내용과 hostname이 동일한지 확인

</etc/hosts 전>

</etc/hosts 후>

ð  host명인 nodeA 추가함

추가한 후 reboot 꼭 해야함.

 

4.4.  The ‘service’ parameter …/conf/cubrid.conf: Unrecognized keyword. Could not load one or more mandatory properties in configuration files.

[에러해결]

ð  home/cub_user/CUBRID-10.1.3.7765-265e708-Linux.x86_64/conf/cubrid.conf 파일의 38줄에 있는 service 파라미터가 Unrecognized keyword라고 해서 service라는 keyword를 지워줌.

<변경전>                                                   

 <변경후>

마찬가지로 The ‘server’ parameter …. /conf/cubrid.conf : Unrecognized keyword 라고 떠서 server 파라미터 지워줌.

 

4.5.  Copylogdb: Copy log pages from the server. Usage: cub_admin copylogdb [OPTION] database-name

Master 서버와 slave 서버가 동시에 켜져있지 않아서 log pages를 copy 실패해서 생기는 에러로 추정.

Master 서버와 slave 서버를 둘다 키는 것으로 에러 해결.

4.6.  to-be-active에서 active로 전환이 안되는 상태.

[에러해결]

ð  master slave 서버 방화벽에서 7,1523,59901 포트 오픈해야함

vi /etc/sysconfig/iptables

service iptables restart

 

4.7.  ERROR: Attempted to update the database when updates are disabled.

위와 같은 에러는 create와 같은 쓰기는 active 서버에서만 할 수 있는데 slave 서버나 to-be-active 서버에서 했을 경우에 에러가 발생한다. active서버에서 하면 이 에러가 발생하지 않는다.