갈레라 클러스터를 쓰고 있으면, 테이블 변경할때 마음의 준비를 좀 하고 DDL 명령문을 날려야한다.
경건하게 ALTER QUERY를 날려야한다
내가 지금 사용하고 있는 DDL 방식이 뭔지 확인해보고, 어떤 테이블들을 변경할건지, 서비스의 특성이 뭔지 등을 고려하여 테이블 변경 플랜을 짜야한다.
갈레라 클러스터에서 DDL 을 처리하는 방법은 두가지가 있다. TOI 와 RSU 방식이다.
Default 방식은 TOI 이다.
TOI
TOI 방식은 클러스터에 묶여있는 DB SERVER들의 테이블들을 한방에 변경해주는 방식이다.
그런데 모든 DB SERVER에서 테이블 변경이 끝날 때까지, 클러스터에 들어오는 트랜잭션들을 처리하지 않고 쌓아둔다.
만약에 세 대의 데이터베이스 서버로 클러스터를 구성했다면,
세 대의 서버에서 테이블 변경이 모두 끝나야만 데이터 UPDATE, INSERT, DELETE가 가능하다는거다.
이 경우 문제가 될 수 있다.
변경해야하는 테이블 크기가 커서, 테이블을 변경하는데 시간이 많이 걸린다면
트랜잭션들이 처리되지 않고, 쌓이다가 데드락이 걸릴 수도 있다.
table 변경 대상이 되는 database가 달라도, 같은 db server에 있으면 트랜잭션들이 다 막히게 된다
Online DDL 방식을 사용하면, 이런 문제를 피할 수 있다고 하는데,
아무튼 TOI 방식을 사용하고 있다면, 이러한 상황들을 고려하여 테이블을 변경해야한다.
RSU
RSU 방식은 클러스터에 묶여있는 DB 서버에서, 직접 한대한대씩 차례대로 테이블을 변경해주는 방식이다.
이 때 롤링스키마 방식이란걸 사용한다. 한 서버에서 테이블이 변경이 끝나고 나면, 그동안 밀렸던 나머지 데이터베이스와의 싱크 작업들이 진행된다.
TOI보다 RSU가 좀더 나은 점은
TOI 는 클러스터에 묶여있는 모든 DB SERVER에 들어오는 트랜잭션을 막아버린다면,
RSU는 지금, 변경하고 있는 DB SERVER에 들어오는 트랜잭션만 막는다는 점이다.
아무튼.. 테이블을 변경하는 동안은 변경중인 DB의 트랜잭션을 모두 막아버린다는건 ROI나 RSU나 똑같다.
그리고 여기서 주의해야하는 점은 DDL이 진행되는 동안 신규 테이블 스키마와 구 테이블 스키마가 공존한다는 점이다.
갈레라 클러스터 환경에서 DDL을 할 때 어떤걸 주의해야하는지 문서들을 찾아봤었다.
관련 문서
갈레라 클러스터 환경에서 스키마 변경하는 방식- schemaupgrades
갈레라 클러스터 DDL 방식 장단점 - online-schema-upgrade-mysql-galera-cluster-using-toi-method
갈레라 클러스터를 잘 쓰는 방법에 대한 pdf - PLNY12-galera-cluster-best-practices.pdf
'소프트웨어-이야기 > 데이터 저장소 + 시각화 ' 카테고리의 다른 글
[리서치]통계 처리 시스템 기업 사례 (0) | 2017.11.11 |
---|---|
[DB] 갈레라 클러스터의 특이한 점들 (0) | 2017.10.23 |
[SPARK] 클러스터 환경 (0) | 2017.09.06 |
[리서치]람다 아키텍처 (1) | 2017.07.22 |
[Spark]User Define Function (0) | 2017.03.11 |