지난 포스팅에서 pglogical을 이용한 DB 이중화 구성을 테스트했을 때, 마지막에 구독을 하고 있는 노드에서 INSERT, UPDATE, DELETE 등의 DML 명령어를 사용했을 때 read-only 모드가 아니기 때문에 값이 DB에 반영되는 것을 확인할 수 있었다.
read-only 모드로 사용하는 방법이던지, 뭔가 다른 방법이 있을 것 같지만 이런 것들을 찾아보기 이전에 양방향 이중화. bi-directional replication 글을 읽었기 때문에 이 방법 먼저 알아보기로 하였다.
https://aws.amazon.com/ko/blogs/database/postgresql-bi-directional-replication-using-pglogical/
단방향 이중화에서는 slave(standby) 상태로 되어있는 노드에서 발생하는 INSERT, UPDATE, DELETE 문은 master 노드로 복제되지 않아 데이터 불일치 문제가 발생하였지만, 양방향 이중화에서는 양쪽에서 발생하는 INSERT, UPDATE, DELETE 문을 서로서로 복제하기 때문에 해당 문제가 발생하지 않는다.
양방향 이중화를 위해서는 이전에 생성한 옵션과 다른 옵션을 주어야 하기 때문에 rocky2 서버에 생성된 구독을 제거해주기로 한다.
SELECT pglogical.drop_subscription('${구독명}') ;
이제 양쪽 서버에 모두 구독을 생성해 준다.
지난 구독 생성과 다른 점은 forward_origins 파라미터를 {}로 설정해주어야 한다.
SELECT pglogical.create_subscription(
subscription_name := '${구독명}',
provider_dsn := 'host=${공급노드 IP} port=${공급노드 port} dbname=${공급노드 DB명} user=${공급노드 유저명} password=${공급 노드유저패스워드}',
replication_sets := ARRAY['default'],
forward_origins := '{}'
);
SELECT pglogical.wait_for_subscription_sync_complete('${구독명}');
forward_origins 파라미터는 값의 기본값은 '{all}'인데, 이는 변경 사항이 발생하면 origin이 무엇이든 모든 변경 사항을 복제한다는 뜻이다. 이를 빈 배열로 설정해주게 되면 공급자 노드에서 시작되지 않은 변경 사항을 전달하지 않도록 설정할 수 있다.
만약 이 파라미터를 빈 배열로 주지 않게 되면 서로 복제된 변경 사항을 계속해서 주고받게 된다.
양 쪽 서버에서 구독을 활성화하였다.
이제부터 어느 서버든 DML 명령어를 사용하게 되면 서로 복제를 수행하여 데이터를 동기화하게 된다.
현재 test 테이블에 기록된 내용이 없는 것으로 나온다.
이제 rocky1 서버에서 INSERT 문을 실행해 본다.
그 후 양 쪽에서 SELECT 문을 사용하였을 때, 데이터가 동기화되고 있는 것을 확인할 수 있다.
이제 양방향 복제가 잘 되고 있는지 확인해보기 위해 rocky2 서버에서 INSERT 문을 실행해 본다.
SELECT 문을 사용하여 정상적으로 복제가 일어나고 있는 것을 확인할 수 있다.
INSERT 문만이 아니라, UPDATE, DELETE 문도 복제가 정상적으로 수행되는 것을 확인할 수 있다.
다만, 양방향 이중화를 사용할 때 문제점은, DDL 명령어를 사용하였을 때 pglogcial은 노드 간에 자동으로 복제를 해주지 않는다.
단방향 복제의 경우 pglogical.replicate_ddl_command 함수를 사용하여 다른 노드에 복제를 할 수 있는데, 양방향 복제의 경우 문제가 발생하게 된다.
또한, 양방향 이중화를 사용할 경우 시퀀스 번호를 연속적으로 발급받을 경우 실시간으로 동기화되지 않기 때문에 이에 대한 문제가 발생할 수 있다.
이 문제점은 각 노드 별로 시퀀스 번호의 형태를 다르게 사용하면 해결할 수 있는 문제다.
아무튼 이렇게 pglogical을 사용하여 단방향, 양방향 이중화에 대한 간단한 테스트를 해보았다.
PostgreSQL 공식 문서에 따르면 논리적 복제를 사용한 이중화는 충돌 문제가 필요하다고 되어있다.
따라서 단순한 테스트는 이렇게 끝이 나지만, 실제로 사용할 때는 이러한 부분들을 고려해서 사용해야 할 것 같다.
'DB' 카테고리의 다른 글
[PostgreSQL] repmgr을 이용한 DB 이중화 구성하기_2, auto failover (0) | 2022.10.02 |
---|---|
[PostgreSQL] repmgr을 이용한 DB 이중화 구성하기_1 (0) | 2022.10.01 |
[PostgreSQL] pglogical을 이용한 DB 이중화 구성하기 (1) | 2022.09.20 |
[PostgreSQL] PostgreSQL 12 설치 후 Job for postgresql-12.service failed because the control process exited with error code. 에러 해결하기 (0) | 2022.09.08 |
[SQL] SQL 문법 간단 정리 (0) | 2021.02.01 |