전환 결정 배경과 검토사항
오픈소스 DBMS 전환의 계기(운영정책·경영진 결정·비용)와 안정성·리소스라는 장애물을 짚는다. 총 소유비용, 전환 후 운영 능력, 장애 대응 체계, 서비스 특성, 오라클 고유 기능 이전 같은 사전 검토 항목을 정리한다.
2014년 장비 통합으로 라이선스 비용을 30억 절감하고 엑사데이터를 도입한 과정을 설명한다. 팀별 N분의 1 비용 청구와 먼저 빠지는 팀만 유리해지는 정책이 발등의 불이 되어 10여 개 서비스가 오라클 페이드아웃에 나선 배경을 든다.
전환을 논의·전환·개발·마이그레이션 단계로 나눠 설명한다. 대상 서비스와 저장소(MySQL·큐브리드 등) 선정, 용량 산정, 오브젝트 오너십 결정, 오라클 고유 기능 개발, 무중단 이관을 위한 자체 트리거 솔루션 제작까지 다루며, 이 과정이 무한 반복됨을 강조한다.
오라클→MySQL 이관의 첫 방법으로 DB 링크(dg4odbc)를 설명한다. 게이트웨이 라이선스 검토, MySQL 커넥터 세팅, odbc.ini·tnsnames 설정 과정을 보이고, 골뱅이 DB링크 구문을 지원하지 않아 커서로 읽어 넣는 방식으로 구현했음을 든다.
캐릭터셋 컨버전이 느린 DB 링크의 한계를 보완하려 오픈소스 ETL 펜타호 PDI를 병행한다. 파라미터 튜닝으로 초당 2~3천 건을 20~30만 건으로 끌어올리고, 공백 데이터가 널 처리되는 문제를 프로퍼티 설정으로 해결한 노하우를 공유한다.
개발·검증·운영 3단계 DB 구성과, 오라클 서비스 하나를 물리 서버 3대로 잡는 용량 산정 기준을 설명한다. NVMe 장착, 로컬 디스크 사용 등 표준 장비 정책과 대략적 산정 후 실측으로 재조정하는 접근을 든다.
실제 오라클 워크로드를 MySQL에도 동일하게 주며 장비가 감당 가능한지 검증하고, 부족하면 스케일업·서비스 분할한다. 임계치 초과 쿼리 자동 차단, MMM·MHA 기반 고가용성, 엑사데이터 1노드를 하둡 44대+MySQL 4대로 전환한 사례를 소개한다.
오라클의 공백 한 칸 데이터가 MySQL 유니크 인덱스에서 패드 스페이스 이슈를 일으키는 문제, 다중 바이트 문자, 콜레이션에 따라 정렬 순서가 바뀌어 랭킹·계산이 틀어지는 함정을 짚는다. 클렌징 후 넘어갈 것을 권하며 발표를 마무리한다.