R E P L I C A T I O N ! ! !
아 이거 좀.. 스트레스 받았던 것 중에 하난데.. 이걸 또 해야하다니 ㅠㅜ.. 다리가 다치고 나서 오랫만에 회사에 복직하자 마자 했던 일이 MySQL Fabric을 사용해서 Sharding 과 Replication을 동시에 하도록 구성하는 일을 했는데.. 특히 MySQL Fabric 을 사용한 설정은 더 많이 없어서 고생했었는데.. Mongo 는 생각보다 잘 정리가 되어있었고 그거 보단 쉬웠던것 같다.
먼저 정리가 되어있는 링크는 여기에 있다. (http://docs.mongodb.org/manual/replication/)
Mongo의 Replica set 은 M-S 의 이야기만 말하고 있는 것은 아니다. Fabric 역시 그랬든 아주 이상적으로 돌아가는 M-S 구조를 만든다는데 촛점이 맞춰져 있는 것이 아니라.. Fail-over 에 대한 이야기라던가.. 어떤 방식으로 복제를 수행하는가에 대한 이야기가 주된 내용이었다.
역시 그렇든 Multi Master 의 개념은 MongoDB 역시 없다. Replica set 에는 딱 한개의 마스터만이 존재할 수 있다. 이 마스터는 Oplog 라고 불리우는 Capped collection (생성된 데이터 공간을 Queue 형태로 관리하면서 순차적으로 데이터를 저장하는 자료구조) 를 사용해서 데이터 베이스의 변경사항들을 저장하고 이 저장된 값들을 비동기식으로 Secondary 에 반영시키는 방식을 취한다.
그리고 Fail-over 시에는 조금 더 독특한 방법을 취하고 있다. MySQL 의 그것과 비슷하게 Secondary 중에 하나가 Primary 로 변경이 되어 가용성을 유지시키는 작업을 수행하는데 이는 선출(election)을 통해서 이루어 진다. 뭔가 replica set 들에게 주도권을 준거 같은 기분이 든다 ㅋㅋ
그리고 Arbitor 라는 기능을 하는 Secondary 를 만들수 있는데 얘는 Replica set 중에 하나이지만 실제 데이터를 저장하고 있지는 않다고 하고.. 이는 단순하게 장애 시에 특정 Secondary를 선출하도록 하거나.. 혹은 짝수만큼의 Replica set 때문에 투표가 부결되는 것을 방지한다고 한다. 이부분이 좀 복잡하긴 한데.. 어쨌든 Secondary 의 역할을 하는 것이 정말 라이브에 필요한 복제가 되기도 하고.. 백업용이 있을 수도 있는 것이고.. 여튼 그러하다.
