왜 Arbiter인가?

지난 3개의 포스팅을 통해 Replica Set과 Election 및 Secondary가 두 개일 경우 Arbiter가 있어야 하는 이유에 대해 알게 됐을 것이다. 그런데 여기서 한가지 궁금한 점이 있을 것이다. 애초에 아비터 없이 Secondary만 3개 있으면 되지 않을까?

아래와 같이 백엔드에서 Read가 600만큼 req가 오고 있는 것이 보일 것이다.

[그림1 Read req가 600인 경우]

Secondary에서 300씩 처리하는데 가장 이상적이라고 한다면 Primary 하나와 Secondary 두개가 가장 이상적일 것이다.

  

[그림2 Read req가 600이고 primary1, secondary2인 rs의 경우]

물론 read req가 900이라면?

 

[그림3 Read req가 900인 경우]

각 Secondary가 300씩 처리하는게 이상적이라면 Primary 하나와 Secondary 세 개가 적당할 것이다.

[그림4 Read req가 900이고 primary1, secondary3인 rs의 경우]

하지만 Primary 입장에서 생각을 해보게 된다면 ‘그림5’와 같이 Primary는 각 Secondary에게 Replication 해 주어야 한다.

[그림5 mongodb rs: Primary1, Secondary2]

Secondary가 세 개라면 그만큼 Primary의 부담도 더 증가 한다는 뜻이된다. 반면 Arbiter는 Primary로부터 Data Replication을 지원받을 필요가 없으며 실제로 지원받지도 않는다. 그저 Primary 선출시 투표권을 가지고 있을 뿐이다.

<출저: https://unagi44.wordpress.com/Developer Lee>