Mysql 5.7 Group Replication

mmm은 실제 운용에 손이 무지 많이 갈거 같습니다. 관리도 힘들고 복구시 손도 많이 가고. 갈레라로 가심이 맞을듯.

"성능이슈"라는 단어 자체를 어느 방향에서 이해해야 할지는 상황따라 천차만별일텐데
그저 간단하게 표현하자면,
제한사항을 잘 지킨 경우라면 크게 문제가 발생하진 않더라~ 정도로 생각하면 될듯 싶은데..
자신있게 뭐라 말씀을 못드리겠네요..ㅠㅠ..

일단은 Galera적용시 제한사항등은 확인을 해야 할텐데요
(Transaction이 너무 크면 안된다던가...Table Lock은 걸지 말라던가..)
제 경우는 개발자들은 따로 있고, 저는 DB쪽만 맞춰서 제공하는 형태인지라
개발멤버에게 제한사항 공유하는 정도로 마무리를 하고
저는 순수하게 DB 설정값 최적화에만 집중했답니다.

..개인적인 느낌은 (제가 DB지식이 미천해서...그저 추상적으로 느끼는 정도인데요)
Galera 만이 아니라 NDB Cluster나, 말씀하신 Group Replication도 그렇고
DB Schema 자체를 그저 "MySQL"이란 대전제로만 정의하고 끝나는 것이 아니라
결국, 각 솔루션(MHA냐 NDB Cluster냐 Galera)이라는 그릇에 딱 맞춰줘야 한다는 느낌이 강하고,
이 솔루션들이 요구하는 부분들이 어찌 보면 부분적으로나마 요즘 말하는 NoSQL쪽의 성격에 조금은 가까워지는 것 아닌가 하는 생각도 들었습니다.
(DB Schema 자체는 단순화 시키고, Scale Out이 용이하도록 조정...)
설정작업 자체의 성격이 이러하다 보니...
Galera에 의한 성능이슈?보다는
결국 Application단에서 Galera와 충돌을 일으킬만한 요소는 없는가? 가 더 중요해지는 듯 합니다.
"조건만 잘 지킨다면 안정성은 약속해주마!" 라고 말하는 듯한..

암튼 큰 문제는 없었고, 자잘자잘한 에러로그와의 지리멸렬한 싸움이 될텐데 그거야 Galera만의 문제는 아니니...
딱히 Galera라서 생기는 문제점은 아직 겪어보질 못했어요.
(적용대상 서비스들이 그렇게 초대형규모가 아니다보니 더더욱...)

그리고, 제 경우엔 애초에 Galera를 도입 안하고
단순히 Master-Slave Replication으로 가더라도 성능상 이슈가 없을 만큼의 H/W기반을 잡아놓고 가는 것이 윗분들의 결정이었기 땜에
더더욱 성능이슈를 겪을 일이 없었답니다...-_-;... ( 전혀 도움이 못돼서 죄송해요... )

제가 지금까지 사용한 형태는 3 Master - 1 Slave 구요
3 Master는 하이스펙으로... 1 Slave는 순수 백업전용이라 기록상의 Delay가 가끔 커지거나 해도 크게 문제삼지 않으니
로우스펙에 스토리지만 큼직허게 물려주는 스타일입니다.
Master 성능이 부족하면 기존 3대와 동일스펙의 서버를 추가해주는 것으로 잠정 약속을 해두지요

+++
추가 잡설입니닷..

Galera Cluster 라면
- Oracle MySQL Community Server -> Codership Ver.
- MariaDB -> Galera Cluster
- Percona -> Percona XtraDB Cluster (PXC)
3대 벤더 중에서 선택하게 될 것인데,

2014년 즈음부터 떠올려보면
그때는 MariaDB Galera Cluster쪽이 문서는 가장 풍부했던것 같고
실적용예를 소개한 글에선 오히려 Oracle-Codership을 많이 접했었는데요

저는 그때 단지, Xtrabackup이 Percona의 생산물이라는 것과 Percona 쪽이 모니터링이 좀 더 용이하다는 설명 때문에
약간은 모험삼아 PXC를 선택했었는데요
대략 2015년 말경?!즈음부터는 사뭇 느낌이 달라져서
Galera 구축 관련 예제로는 최근으로 올 수록 Oracle | MariaDB 보다도 PXC가 압도적으로 많아지고 있다고 느낍니다.
그래서...요즘은 그냥 PXC로 고정!!!입니다.

그에 더해서...
저는 처음 Galera를 건들때부터 (지금까지도) DB관련해서 도움받을 사람이 전혀 없는 상황인지라
시작 단계부터 추가솔루션을 같이 고민해가며 진행을 했었는데요
모니터링 포함 자동배포기능등을 포함하고 있길래 선택해서 지금까지 유용하게 써먹고 있는게
ClusterControl 이라는 놈입니다.
초기엔 버그도 정말 많았고(지금도 자잘자잘한 문제점들이 보이기야 하지만...),
오히려 수동으로 작성하면 없을 문제가 자동배포 때문에 발생하거나 하는 경우도 많이 겪었었지만,
결과적으론 ClusterControl이 제공하는 정보 및 설정방식등이 학습 면에서 많은 도움이 되었구요
조금은 더 빠른 시일내에 최적화 과정을 마무리할 수 있었습니다.
(MySQL & Galera 뿐 아니라 ClusterControl 까지 같이 공부하고 테스트 모델 만들기를 진행했습죠)

ClusterControl 이 30일 트라이얼로 전체 기능 제공하고,
30일 경과하면 상당히 많은 부분에서 기능제한이 걸려버린다는게 좀 아쉽긴 한데
개인적으로 Galera 구축 작업 관련해서는 단순히 자동배포 관점 뿐만 아니라
다양한 정보를 좀 더 집약적으로 빠르게 접할 수 있다는 점에서 정말 많은 도움이 되었습니다.

사정상 유용한 정보를 얻는데에 30일이 지나버리면...참 아쉬운데
이런 경우를 대비해서 아예 처음부터 ClusterControl을 Docker Container Image 형태로 준비를 해둔다던가 하면
기간 끊기면 걍 새 Instance로 갈아치우는 식으루 꼼수를 발휘...
( 다른 신규 Instance에서 라이센스키만 가져온다던가 하는 수도 있겠지만...
...양심의 가책을 느끼기에...ㅠㅠ..)

결국...ClusterControl은 학습 초기에 "나"의 무지함을 채워 줄 도구로서만 활용하고,
ClusterControl이 제공하는 모니터링/Proxy관리/백업스케쥴 등의 주요기능은 처음부터 사용을 안하는 쪽으로 정했습니다.
순수하게 초기 구축단계의 구축/구조변경/설정최적화에 대응하기 위해서만 활용하고
실운용관련 준비(모니터링/Proxy관리/백업)는 독자적으로 준비를 했습니다. (특정 솔루션에 대한 의존성을 최소화)

PXC를 기본으로 하고,

LB/Proxy 는 haproxy + keepalived
(비교적 가장 관리하기 쉬운 구성이라 하데요. 성능면에서 최선은 아니랍니다. 참 무난해요)

정기 Backup은 XtraBackup -> 풀백업 & 증분백업
(Galera의 Sync 솔루션으로 Rsync와 XtraBackup 중 선택하게 될텐데
PXC의 경우 Dependency로 인해 패키지가 기본으로 딸려와요.
자연스레 동기화도 백업도 XtraBackup으로 정리하게 되었습니다. )

모니터링은 이것저것 덕지덕지
(어차피 모니터링은 별도의 영역으로 잡고,
주구장창 개선/갱신해나가야 한다고 생각되서...)