그래.. 2년전엔 생까더니 보다보니 맞는거지.. case closed 까지 시켰다가 지금와서 reveal하는 이유는 뭘까
이제와서 패치한다고 메일질하면 기뻐할줄아는가
이미 mysql의 신뢰도는 개판으로 떨어진거다. 왜?
1. 개발자의 건의를 case closed 로 test result 조차 내지 않고 무시한다.
2. 기능에 이상이 있는걸 2년이나 지난 지금에서야 알아냈다.
3. 지금에서야 패치했다. 그렇다면 그 개발자들은 최하 2년이 넘는 기간동안 정말 단순한 오류하나를 못잡았다는 이야기가 아닌가?
4. 지금에라도 인정을 하니 다행이다 외국기업의 차이겠지만, 그 단순오류 하나때문에;; 시간적 기간적 손실은 크다. 이게 오라클이었으면 소송감이다.
5. 거기다 적용버전은 6.0이다 앞으로 3년은 지나야 이제좀 안정적이겠거니 할듯하다. 한마디로 떡밥이다.
6. 결정적으로 이거때매 검색시스템 새로 구축한다고 삽질한거 외주 인건비로만 쳐도 수천은 들어갔고 시스템 구축비까지 갔다치면 3억은 든다.
결국 bdb 가 윈이란 소리다.
그리고 그때 제기했던 mysql-cluster 에 대한 이슈는 아직도 해결되지 않았다.
slrclub 규모를 mysql-cluster로 올리려면 300기가의 물리적 메모리가 필요하다.
메모리 장사할려고 작정헀나보다. 이게 웃긴게 -_- 1기가짜리 db가 utf-8 로 변환되서 메모리에 올라가면 몇배수로 용량을 잡아먹기 시작한다.
사실 답변은 받았다... "원래 시스템이 그렇다.. 그러니 다올리지 말고 쫌만 올려 써라" 였다.
클러스터링하나 똑바로 안되서 테이블을 쪼개갖고 그걸 프로그래밍으로 해결하라고??
그러니까 오라클이 팔리는거지
전화질이라고 할려다가 천년만년 mysql 쓸것도 아니고.. com이 아니라 ab다.. 두렵다 -_-;;
난 거기서 제일 궁금한게. 모 통신사가 클러스터링을 쓴다는거다. 양키들이라 영어만 쓰니 무관한건지는 모르겠으나 양이 상당할텐데 무슨 슈퍼돔에다 mysql돌리는게 아닐까 하는 생각이 든다. 메모리 20테라 쳐박고.
현재는 mysql 5.1 까지 테스트를 했고 실제서비스에서 동작한지가 어언 1년이 다되간다..
이넘은 리플리케이션 티어로 돌던놈이다..
별다른 문제가 없어보였으나 오늘 막상 안정버전인 5.0 버전을 적용하자마자 (주데이터베이스라)
기현상이 발생하기 시작했다 -_-;;
inner assoc type 의 select query 한방에 전체 데이터베이스가 락이 걸리는 현상이다.
서로다른 3개의 쿼리를 natural과 cross 조인으로 묶고 이를 그루빙한 subquery 를 associative 로 다시 매핑하는 형식의 쿼리다. 그렇다 -_- 통계용 쿼리다.
reference rows도 몇천만개 안된다. 한번돌리고 정신이 멍해졌다...
이거 뭐 트랜잭션 건것도 아닌데 장난하나 -_- 기본으로 트랜잭션이 걸리게 바뀌었나? 건 짐부터 찾아봐야될 문제다.
critical changed issue 를 요약정리를 하는 센스가 없다. 세줄요약이 괜히나온말이 아니다 -_-
5.1 버전대의 큰 변동사항은 매뉴얼 하단에 몇줄 박혀있는걸 보았다. (통상 업그레이드 안내측에 위치한다) 그러나 이내용은 여기에 없다.
release note, change history 를 당장급한데 수십페이지나되는걸 하나하나 정독하고 있어야할판이다.
혹시 누구 정리한사람있으면 링크하나 던져줬음좋겠다.
이틀 잠도 제대로 못자 정신이 멍하다 -_- 거기다 이놈이 막타를 치는구나.
5.0.45 (몇일전까지 GA 릴리즈였던) 버전에는 메모리 리크 결함이 있다. 지금 사이트에 가보면 5.0.5x 로 버전이 변경되었다.
이녀석이 불러일으킨 트러블이었다. 5.0.45 사용자는 즉시 버전업을 할것.
(0) 
(0)Posted by LeCieL