작성
·
771
0
안녕하세요!
평소 궁금했던 내용들이어서 강의 정말 잘 듣고있습니다.
HA Fail-over 강의에서 "시스템 장애"라는 상황을 가정해서 실습하는 것으로 이해했습니다.
제가 궁금한 부분은
"시스템 장애"라는 문제를 간략하게 "MasterDB 작동이 중지되었다(실습에서 강제로 중지시키는 부분)." 것으로 시스템 장애 상황을 대체해서 설명해주셨습니다.
해당 부분에서 제가 생각했을 때, "시스템 장애"가 DB가 멈춘 것 외에도 다양하게 있을 것 같습니다.
(경험이 없어 정확한 비유일지는 모르겠으나)
예를 들어, DB와 서버간의 IO connection이 받쳐주지 못해서 DB에 데이터를 저장하지 못한다던지..? 혹은 DB rollback이 제대로 작동하지 않는다던지?
혹시 "시스템 장애"에 대해 사례가 있다면 답변해 주시면 더 공부해볼 수 있을 것 같습니다.
부족한 질문이지만 끝까지 읽어주셔서 감사합니다! :)
답변 1
1
안녕하세요.
다양한 시스템 장애에 대해서 문의해 주셨는데요.
말씀하신 것처럼 시스템의 장애는 종류도 다양하고 이에 따라 처리/대응 방식도 달라질 수 있습니다.
DBA의 관점에서 볼 수 있는 장애는 대략적으로 아래와 같이 구분 해볼 수 있겠는데요.
HW 장애(DB서버의 문제)
DB서버에 하드웨어적인 문제가 생겨서 서비스가 불가한 경우 보통은 부품의 교체나 최악의 경우
서버의 교체가 필요할 수 있기 때문에 Master 서버의 장애가 발생한 경우는 Slave로 빠르게 Fail over를 해주고 문제가된 서버를 교체해서 데이터를 복구한 후 변경된 Master의 Slave로 다시 추가해 줍니다.
SW 장애(DBMS SW의 문제)
MySQL 자체의 문제(버그)로 서비스가 불가한 경우 원인을 빠르게 찾아서 해결할 수 있으면 좋겠지만 그렇지 못한 경우는 빠른 서비스 복구를 위해서 문제가 되는 Master 를 Slave로 Failover하고
기존 Master의 SW적인 문제를 해결한 후에 데이터를 복구해서 변경된 Master의 Slave로 다시 추가해 줍니다.
Network 장애(App서버와 DB서버간의 중단 or Master와 Slave사이의 중단)
Network 장애인 경우는 좀 더 다양한 케이스가 있을 거 같은데요.
App-Master 간의 문제가 있고 App-Slave간에는 문제가 없는 경우 역시 Master를 failover해서
연결이 가능한 Slave를 Master로 승격시켜서 서비스를 지속시킬 수 있습니다.
App-모든DB서버 간에 네트워크 연결이 불가능한 경우는 DB레벨에서 조치할 수 있는 게 없고 네트워크 엔지니어를 통해서 네트워크가 복구될 때까지 기다리는 방법밖에 없을 거 같습니다.
이외에도 더 다양한 케이스가 있을 수 있겠지만 일단 쉽게 떠올릴 수 있는 것들은 이 정도인 거 같습니다.
감사합니다.
안녕하세요.
사용하는 DB제품에 따라서 말씀하신 구성도 가능합니다.
예를 들면 Percona xtracluster 같은 경우에는 말씀하신 구성으로도 사용이 가능할 거 같습니다.
하지만, 보통 실무에서 사용할때는 app서버와 db서버 사이에 proxy layer를 두고서 proxy layer에서 커넥션을 컨트롤 하도록 해서 사용하는 경우가 많습니다.
답변 감사합니다 :-)
문득, 떠오르는 생각은..
server - MasterDB - SlaveDB 구조(1-1-N)를
아래의 구조처럼 server 1개에 직접 여러 DB를 연결할 수 있을 것 같은데(1-N).. 이런 방식은 채택하지 않는지 궁금합니다.
server(같은 서버) - MasterDB1
server(같은 서버) - MasterDB2
server(같은 서버) - MasterDB3
이렇게 생각한 이유는
서버도 1개일 경우, 단일 장애 지점의 우려가 있어 여러개의 서버를 두는 것으로 알고 있는데...
이런 맥락에서 "1개의 서버에 직접 여러개의 DB를 연결시켜놓으면 Fail Over를 하는 상황에서도 좀 더 빠르고 쉽게 대처할 수 있지 않을까? 장애가 생긴 DB만 연결을 끊으면 되지 않은가?" 라는 생각이 들어서 입니다.