그날, 그리고 그날을 회고하며.
DEVIEW 이후 받은 질문, 당장 생각나는 머릿속 이야기 끄적임
10월 크나큰 마음의 부담을 가졌던 DEVIEW 가 끝이 났다. 아직 부족한 실력에, 우리의 사례를 공유하는 자리인만큼 긴장도 많이 했고.. 떨기도 많이 했고.. 그래도 못보던 사람들을 갑자기(!!) 만나서 참 좋았고.
쉬고 있을 틈은 없어 보이지만.. 일단 달렸으니, 이번주는 고기를 뜯으면서 우육인생을 한번 누려보세. 크헛헛헛~ 그냥 머리를 비운채 생각나는 내용만 대충 끄적여봅세.
데뷰의 첫 컨셉은, 은행에 오픈소스 데이터베이스 도입 사례 얘기였던지라.. 사실 발표 내용보다 훨씬 전반적으로 내용을 담기는 했었다. 물론, 피드백을 받아서, 도입 사례 중 한두개 정도에 포커스를 맞춰서 조금 더 상세하게 설명을 하는 식으로 바꾸기는 했지만.. ^^
https://www.slideshare.net/deview/135-80845610
이후 들은 질문 대략 몇 가지를 얘기하자면.. (단, 개인 생각일 뿐. 맹신은 금지!)
1. lossless replication이 semi-sync replication인가요?
네. 맞아요. 5.7에 소개된 AFTER_SYNC 방식입니다.
2. GTID + semi-sync 조합은 어때요?
GTID는 트랜잭션이 리플리케이션 세트 안에 유니크한 아이디를 보장하므로, 노드 추가/삭제/위상 변경에 용이합니다. MHA에서도 MySQL GTID 모드를 제공하니, 관리 측면에서 잇점이 있겠네요.
아, 저는 아직은 기존 사용하고 있지는 않아요.
3. MHA쓰면 MyISAM은 어떻게 관리해요?
리플리케이션을 쓰는 이상은 MyISAM엔진에는 서비스 데이터를 넣지 않아요.
테이블 잠금에 트랜잭션 안되는 것 만으로 포기해야할 것도 많을 뿐더러, 이미 전문검색/공간트리와 같은 기능은 InnoDB에 구현되어 있기 때문에 굳이 무리하면서까지 써야할 필요는 없어요. 게다가 트랜잭션이 지원 안되기에.. 아무 생각없이 슬레이브 재시작 하는 것만으로도 리플리케이션이 깨질 소지가 있습니다.
4. 마스터/슬레이브 동시에 죽어버리면 어쩌죠?
이런 경우는 분명 홀이 있죠. 그런데.. 저 두대 동시 셧다운은.. 사실은 주센터 서비스 장비 모두 날라가는 것이라.. -_-;; 더욱 견고한 데이터 안정성을 위해서라면, Binlog Server하나를 두고 마스터에서 2대 서버 응답 올때까지 잠시 기다리게 하는 방안이 있겠다만. 적절한 타협점을 고민할만큼의 리스크로 보이지는 않는군요.
5. mysqld가 예기치 않게 재시작되어도 페얼오버가 잘 될까요?
mysqld가 죽었는데, mysqld_safe가 부활 시킨 경우에 대한 MHA대응..
innodb_temp_data_file_path를 10G 정도를 할당해서.. mysqld가 순간 죽었다가 살아나도 10초 이상(적어도 대략 20초 소요) 걸리도록 유도했어요. 무조건 장애난 것으로 감지됩니다.
모든 것을 조화롭게..ㅋㅋ 왼손은 거들 뿐..
사실 이런 것 말고도, 재미난 주제는 많았다. 애초의 은행 사례 공유를 목표로 하지 않고, 난관 극복 정도의 기승전결을 읊었다면, 훨씬 공감이 가는 이야기를 풀어낼 수 있었을 것 같다.
예를 들어..
MySQL 5.7에 처음 소개된 ngram 전문 검색 엔진을 어떤 과정을 거쳐서 실 서비스에 적용하게 되었는지, 가용성 테스트를 하면서 도메인에서 socket timeout이 미친 영향. dentry 메모리 점유 현상이 발생했고, 실 서비스 오픈 시에도 이 이슈로 달리는 기차의 바퀴를 바로 갈아끼었던 아찔했던 순간! (물론 커졌다고, 서비스에 당장 문제 요소는 아님)
일하기 싫어서, 어떻게든 유지 관리 안하도록 자동화한 것이나 데이터베이스이 빅브라더가 되기 위해 매니저에 끼워 넣은 내용~ 내가 살기 위해 패스워드 관리 시스템(이거 요약해서 얘기해도 될까요? 회사님아!)을 직접 구현해서 지금도 쓰고 있는 것. 접근 제어 솔루션과 테드폴 연동시 발생했던 Oracle 버전별 클라이언트 패킷 차이(11gR2경우에는 64byte마다 다음 글자 수를 명시해줌)
샤드 간 유니크한 정수 타입 아이디 발급 규칙과 이를 활용한 파티셔닝 관리. (전 직장에서 만들었던 것 업그레이드 버전) performance_schema에 추가된 events_statements_summary_by_digest 값을 주요 서버 매분 수집하면서 유입 쿼리 분석하고 변태 튜닝 것. (참고로 공유 버전으로는 SQLite 버전을 준비하다 말았음 -_-;;)
무중단 샤드 분리 방안과 적용 과정 등등등등. 게다가 이왕이면 향후 더욱 커졌을 때 "데이터 클라우드" 달성을 위해 고민하고 있는 유연한 데이터 재분산 방안 등등.
당장 기억난 것만 끄적끄적 대충 적었지만.. 이런 주제에 참으로 재미를 느낀다면, 참으로 2박3일 얘기를 즐겁게할만한 소재가 많이 생긴 듯 하다.
하고 싶던 또다른 이야기는. 바로 이거.
"데이터"를 보고 결정을 하자
왜냐하면 나는 데이터쟁이이기 때문에.. 이 데이터는 무엇이고, 무엇을 위한 것이고, 무엇을 하고 싶고, 라이프사이클은 어떻고.. 알고리즘 위에서 데이터는 어떻게 움직이는지.. 나름 이런 것 위주로 고민하고, 결정하고, 구현하였다.
지금도 그렇지만.. 있어보이려 노력한다만.. 지금도 여전히.. 지금 이렇게 구성하고 결정하고 운영하고 있는 것에 대해, 책임지겠다는 마음가짐으로.. 오늘 하루도 덜덜 떨면서 아무렇지 않은 듯 있어보이는 척(!)하며 여유있게 지내본다. ㅋㅋ 문제 생기면 가장 큰 잘못은 나로부터 비롯된 것, 그렇기에 그건 내 책임~ 쿄쿄
이제, 또다른 공간에서 공유할 수 있는 날을 준비합세.
