대용량 서비스 이슈. mysql 리플리케이션
mysql db를 이중화 또는 로드발란싱 하는 방법은 크게 두가지가 있습니다.
1. 리플리케이션
2. 클러스터
2. 클러스터
지금 이중에서 1번 리플리케이션을 구성하고 있는데,
리플리케이션은 보편적으로 1대의 마스터와 N개의 슬레이브를 두어서
1개의 마스터에 INSERT/UPDATE/DELETE 작업을 하고,
N개의 슬레이브에는 SELECT를 하게 됩니다.
(좀더 복잡하게 할려면 2개의 마스터를 두어 이중화 할수도 있습니다. 이건 복잡하니 빼고)
리플리케이션은 보편적으로 1대의 마스터와 N개의 슬레이브를 두어서
1개의 마스터에 INSERT/UPDATE/DELETE 작업을 하고,
N개의 슬레이브에는 SELECT를 하게 됩니다.
(좀더 복잡하게 할려면 2개의 마스터를 두어 이중화 할수도 있습니다. 이건 복잡하니 빼고)
지금 그누보드를 이 리플리케이션 구조에 맞춰야 하는데,
뭔가 좋은 방법을 찾고 있는 중입니다.
현재 그누보드는 CRUD 작업을 모두 common.lib.php 의 sql_query 로 처리하고 있습니다.
불행히도 sql_update 는 없음.
게다가 sql_connect, sql_select_db도 고정값을 쓰죠.
문제
그누보드에서 INSERT/UPDATE/DELETE 작업을 A db서버로 하고
SELECT 작업을 B db서버로 해야 하는 경우
그누보드 구조를 최소한으로 변경하고, 소스수정을 최소한으로 해서
적용하는 방법을 제시해주세요.
그누보드에서 INSERT/UPDATE/DELETE 작업을 A db서버로 하고
SELECT 작업을 B db서버로 해야 하는 경우
그누보드 구조를 최소한으로 변경하고, 소스수정을 최소한으로 해서
적용하는 방법을 제시해주세요.
|
댓글을 작성하시려면 로그인이 필요합니다.
로그인
댓글 18개
sql_query 에서
sql 문이 INSERT, UPDATE, DELETE 로 시작하는 경우 A 서버로 connection 시킨다음 작업 완료후
다시 B서버로 접속시켜놓을려고 합니다.
이 경우 한 페이지 여러 crud 가 섞이는 경우 connection 을 너무 빈번하게 호출한다는 문제가 있습니다.
connection 객체를 두개를 만들어둘까 하는데, 이것도 별로 바람직해보이지는 않습니다.
A 서버로 불필요한 컨넥션을 만들게 됩니다.
사용자수가 많아서 DB를 분산하는것이라면 차라리 DB 서버를 빠방한걸로 하나 두고,
웹서버를 여러대 두고 웹쪽을 부하분산하는게 나아보이는데요.
아무리 빠방해도 동접에는 장사가 없습니다.
초당 5000 query를 처리할수 있어야 합니다.
분산시키면 한개의 db서버가 1500-2000 query만 실행할수 있으면 되니까요.
분산의 목적은 cpu의 속도보다는 네트웍과 io의 부하때문입니다.
CPU의 한계라기보다 CPU FSB의 한계라는게 맞을겁니다 FSB가 빠방한게좋고
그리고 서버가 분리되게되면 디스크io에서 효율성이 떨어집니다
네트웤도 마찬가지로 묶인놈이 단일서버를 따라오긴 불가능합니다
LAN도 분산하지 라고 하시는분 많으신데 왠만한 중소규모DB는 분산할 라인비용으로 단일라인 쓰는게 더 효율적이에요
위와 같이 네트웍과 네트웍 및 IO자원이 지나치게 많이 사용되게 되어 이를 줄이는게 목적이었습니다.
마스터 db가 있고, 이 마스터 db를 보고 있는 슬레이브 db들은 모두 web서버가 같이 설치되어 있습니다.
대략 다음과 같은 구조입니다.
master db(A) ------ slave db1(B) + web1
+- slave db2(C) + web2
+- slave db3(D) + web3
+- 접속자 증가시 추후 확장
이경우 mysqli connection 를 이용하여 tcp/ip socket이 아닌 unix_socket 을 사용하여, db서버의 time_wait를 최소화 합니다.(사실 발생안시킨다고 보면 됩니다.)
빠방한서버로 딸리신다면 그누를 건드리는것보다 클레스터링 시키는게 서버리소스면에서 효율적일것 같은데요
장애 생기면 복구시간이 클러스터링이 오래 걸릴것 같아서, 리플리케이션으로 간거거든요.
클러스터링은 한서버가 죽으면 둘다 죽는거라서. 문제가 쵸큼 있을것 같더라구요.
이미 하드웨어 셋팅은 끝난거라서...아웅
저는 리플리케이션을 그다지 신뢰하지 않는 편이라....
돈 ㅈㄹ로 장비를 최대한 올리는게 여러대 두는거보다 낫다고 생각하는 주의입니다.
리플리케이션 깨지면 그거 또 언제 싱크 시키고 작업합니까 ㅠ.ㅠ
이미 서버 구성이 끝났다니.
쿼리를 쪼개는 수밖에 없겠네요.
tcp/ip의 connection에 의한 time_wait가 문제가 됩니다.
INSERT 가 일어나는 마스터 서버쪽으로 네트웍 부하가 몰리는건 당연하지 않을까요.
데이터 복제가 일어나야 하니깐요...
저도 초보때 lan wan 디스크io cpu 이것저것 다 클레스터링도해보고 가상화도해보고 삽질끝에 걍 단일서버나 블레이드가 짱이더군요
ps)SELECT는 당근 마스터에서...
2안은 common.lib.php 에 sql_update 함수를 하나 더 추가하고
sql_query() 함수 인자의 insert/update/delete 쿼리문을 모두 찾아서 sql_update로 바꿀생각입니다.
아마 실수를 미연에 방지하기 위해 1안과 2안을 모두 쓸거 같습니다.
좀더 좋은 방법이 없을까요?
중간에 마스터 혹은 다른 로드밸런스 장비가 처리하게 되는거 아닌가요 ?
리플리케이션의 개념을 그렇게 알고 있었는데
도입 여부만 검토하다가 실제로 적용한 건 아니라서
조금 더 찾아봐야겠네요.
지금 하는 작업은 db를 여러대로 나누어서 db에 걸리는 부하를 줄일려고 하는것입니다.