ㅎㅎ 늦었네요 이전에 질문에 답변 드렸는데요 ..^^;

확인 해보세요 ^^

아.. 답변 감사드립니다..

제가 말씀 드리는건 mysql 커넥션을 종류별로 분류를 한다고 해도 우선 쿼리에 있어서

마스터 , 슬레이브가 결정이 된다는 이야긴데요..

즉 커넥션별 설정파일이 여러개가 있어도 쿼리에 선택권이 있다는 겁니다.

a , b , c , d 서버에 대한 설정파일이 여러개가 있어도 쿼리가 update , delete , insert 이면 무조건 마스

터 서버로 커넥션이 이루어져야 하고 기타 나머지 쿼리라면 랜덤으로 슬레이브 어떤 서버로의 커넥션이

되어도 상관이 없구요..

ㅎㅎ 

말씀하신 부분은 대략 알고리즘을 구현하는거에 가깝게 느껴지네요  ^^;


문자열 함수를 써서 앞부분 select를 확인해서 랜덤으로 보내는 부분을 구현해야할듯한데요 ^^;


저희 팀 같은경우에는 코딩하면서 실행위치를 지정해주기때문에 이러한 알고리즘을 만들 필요가 없어서요 이부분에 대해서는 저희도 구현한적이 없어서.. 도움이 못되드리네요.


건승하시고 나중에 후기 부탁드립니다 ^^;

로드벨런싱에 관한 부분은 미들웨어를 통해서 적절히 분기해주어야 겟죠...

모든 쿼리는 미들웨어로 접속하고 미들웨어에서 설정한것대로 이쪽서버로 갈지 저쪽서버로 갈지 정해주는...뭐 방법론적으론 그렇습니다만...

뭐 간단하게...업데이트 쿼리들은 마스터로...그외 Select 는 그때상황에 맞께 아무데나...이렇게 한다고 하면 좀 쉬울텐데요..^^ (Select 쿼리들을 그때 그때 서버상황에 맞추어 분기한다는것 까지 정하면 할일이 많겟죠..각 서버단별로 커넥션도 관리해야 할것이고...쿼리가 몇개나 걸려있는지...기타등등...)

일단 select last_insert_id() ; 와 같은 업데이트쿼리에 영향을 주는것들도 마스터로 분기가 되어야 하는것은 정책을 정해주면 되는것이고...어떠한 쿼리들이 쓰이는지 이것이 업데이트쿼리에 영향을 주는것인지를 먼저 파악을 해야겟죠..뭐 쿼리파싱문제는 그다지 어려운건 아니니깐...

그리고 슬레이브 서버로 분기된 쿼리들이 수행시간이 늦는것은...설정상의 문제인듯 보입니다. (마스터랑 하드웨어적으로나 소프트웨어적으로 같은 상태라면...늦을 이유가 없겟죠?) 

여튼 건승을...

아..모두들 답변 감사드립니다..

일단 지금 현재 해결한 점은

데이터베이스의 클래스를 두개를 만들어 각각 쿼리를 찾아 다니면 select 는 슬레이브 클래스를

나머지 쿼리들은 마스터 클래스를 사용하게 해놨습니다.

일일이 노가다 하느라 오래걸렸지만 서도.. 일단 구동을 시켜보니 예전에 비해 눈에 띄게 속도가 빨라

졌습니다.

한가지 문제점은 mysql_connect 란 함수를 사용시 처음 커넥션이 연결이 되면 mysql_close 를 하기 

전까지는 커넥션이 유지가 된다는 겁니다.

이것때문에 많이 헤맸는데요.. ㅎㅎ 저희 경우는 셀렉트를 하면서 중간중간 업데이트가 날라가는 부분

이 있어 이부분의 경우는 그냥 전부 마스터에서 처리를 하도록 했구요..

뭐 기타 별다른 특이 사항은 없었네요..

하지만 이제 부터의 과제는 매번 슬레이브 서버가 추가 될때마다 이럴순 없잖아요..

뭔가의 대책을 세워야 할거 같은데.. 좋은 방법을 찾고는 있습니다.

박성원님의 방법이 저희랑 비슷한 방식인거 같긴한데요.. 대량의 슬레이브 서버일때는 생각을좀 하셔야

할듯한데요.. teamb 님의 방식은 좀 연구를 해봐야 할거 같습니다.

아무쪼록 바쁜시간 내주셔서 답변해주신점 감사드리구요.. 다들 즐프 하세요..