'SequelSafe'에 해당되는 글 1건

  1. 2018.08.21 About Sequel SAFE (9)
2018. 8. 21. 21:32

배경

1972년 E.F Codd 박사에 의해 RDB 이론이 소개된 이후 여러 벤더가 RDBMS를 개발하였고, 다양한 third-party가 IDE, 백업 및 복원, 모니터링, CASE 도구와 같은 영역에서 경쟁하고 있습니다.

레드 오션을 방불케하는 비슷 비슷한 기능들의 경쟁 속에, 현업에서 절실히 필요로하는 이 기능 만큼은 어떤 도구도 제대로 지원하고 있지 않은데, 그것은 바로 형상 관리입니다.

데이터베이스 형상 관리란, 데이테베이스를 구성하는 각 객체 - Table, View, Index, Stored Procedure, Function, Trigger, etc - 와 데이터베이스 자체에 대한 버전  관리를 기반으로 변경 사항을 체계적으로 추적하고 통제하는 것입니다.
다른 소프트웨어와 마찬가지로 데이터베이스 역시 형상 관리가 필요합니다.
데이터베이스 변경의 원인을 알아내고 제어하며, 개발 단계 뿐 아니라 유지 보수 단계에서도, 현재 적절히 변경되고 있는지 확인하는 일은 어느 DB 조직에서나 원하는 일이기 때문입니다. 또한 개발 과정에서 발생하는 문제 요인을 최소화함으로써 소프트웨어 개발의 전체 비용을 줄일 수 있습니다.
데이터베이스를 형상 관리한다면 배포 역시 체계적이 됩니다. 즉, 더 이상 Diff. 도구로 개발 DB와 프로덕트 DB의 차이점을 비교해 마이그레이션 스크립트를 작성할 필요가 없습니다. 이미 데이터베이스에는 명확한 버전이 부여되었으므로, 관리자는 배포할 버전을 선택하기만 하면 됩니다.

소개

Sequel SAFE for MS-SQL로 명명된 이 도구는 2009년 이곳 블로그에 소스 코드를 공개하였고, 대표적으로 Eyedentity Games에서 2010년 이후 현재까지 데이터베이스 형상 관리 및 생산성 도구로 사용되고 있는 Script Set 입니다.
Eyedentity Games가 개발한 온라인 MORPG인 드래곤 네스트는 10개국 퍼블리셔(파트너)를 통해 40여개 국가에 서비스되고 있으며, Sequel SAFE는 형상 관리 도구, Stored Procedure 작성을 지원하는 생산성 도구, 그리고 배포 도구로서 크게 기여하고 있습니다.
2016년에 MySQL의 형상 관리에 사용할 수 있는 Sequel SAFE for MySQL로 포팅하였으며, 현재는 단순 스크립트 셋이 아닌 웹 UI를 갖춘 형상 관리 도구의 모습이 되었습니다. 이 버전 역시 최근 2년여 동안 여러 프로젝트에 사용되고 있습니다.

기능 (각 기능에 동영상 링크 포함)

설치하기

가지고 있는 AWS 계정이 있다면 아래 링크한 가이드 문서를 참고하여 설치하시기 바랍니다.

피드백 남기기

공개하는 버전은, 데이터베이스 개발자로서 개인적으로 사용하기 위해 만든 툴이다보니, 공개하기에 부족한 면이 많습니다.
제품 수준까지 끌어올린 버전을 준비하고 있으니, 부족한 부분에 대해 댓글을 남겨 주세요.


'MySQL > Sequel SAFE for MySQL' 카테고리의 다른 글

About Sequel SAFE  (9) 2018.08.21
데이터베이스 형상 관리  (7) 2018.05.04
Posted by 르매

댓글을 달아 주세요

  1. 2019.03.28 16:31  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  2. 나루 2019.04.24 16:44  댓글주소  수정/삭제  댓글쓰기

    ddl문을 추출하기 위해 mysql.general_log테이블말고 파일이나 다른 테이블로 변경이 가능할까요?

    • BlogIcon 르매 2019.04.25 10:43 신고  댓글주소  수정/삭제

      배경을 먼저 설명드리면..

      MySQL에서 실행된 DDL을 DBMS에서 직접 추출할 수 있는 방법은 general log와 binlog 밖에 찾지 못했습니다.

      하지만 binlog에는 (1) DDL이 실행된 날짜가 남지 않는 문제, (2) DDL이 포함된 루틴을 실행했을 때에도 DDL이 기록된다는 문제가 있어서.. 형상 관리에 부적합했습니다.

      general log에도 큰 문제가 있는데, 실행이 실패한 DDL도 그대로 남는 (성공/실패 여부를 확인할 방법이 없음) 문제입니다.

      지금 단계에서는 general log에서 DDL을 추출하고, 추출한 DDL을 다른 인스턴스에서 실행해서, 실행에 성공한 DDL만 기록하는 방식을 사용합니다.

      대안으로 general log에서 추출하고 binlog에서 성공 여부를 확인하는 것을 생각하고 있습니다.

      질문해 주신 내용으로 넘어와서, 앞서 설명드린 배경 때문에 general log를 사용해야 합니다.

      다만, general log는 파일로 기록할 수도 있으니.. 테이블 대신 general log 파일을 읽는 프로세스를 고려해 볼 수는 있겠습니다.

      혹시 general_log 테이블을 사용할 수 없는 이유가 어떤 것인지 알려 주실 수 있다면 댓글 부탁드리겠습니다.


  3. 나루 2019.04.26 11:37  댓글주소  수정/삭제  댓글쓰기

    말씀하신 것처럼 저희 시스템은 general log를 파일로 기록하고 있습니다.

    저는 AWS RDS를 사용하고 있으며, 서비스가 중지 되더라도 확인할 수 있도록 파일을 선택하였습니다.

    추가적인 문의로 live DDL문 배포 시 고려사항은 없을까요?(ex 배포 시점에 해당테이블을 장시간 수행하는 세션이 존재하는 경우, DDL 자체의 수행시간이 오래 걸리는 경우 등)

    • BlogIcon 르매 2019.04.27 11:38 신고  댓글주소  수정/삭제

      1. general log를 주기적으로 읽어서 SP를 호출할 수 있는 환경이라면, 제가 그 용도의 SP를 추가하고 알려드리겠습니다. (비밀 댓글로 이메일 주소 남겨주세요)

      2. Online DDL 에 대해서 숙지하실 필요가 있습니다.
      https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html

      위 문서를.. 사용하고 계신 MySQL 버전 기준으로 확인해 보셔야 합니다.

      Only Modifiers Metadata 항목이 Yes인 작업은 안전하지만, 그렇지 않은 항목의 DDL은 테이블의 레코드 수에 비례한 시간만큼 배타 잠금이 걸린다고 보시면 됩니다. 다만, Aurora를 사용하신다면 저 문서와 차이가 있는데, 그 부분은 AWS의 문서를 찾아 보셔야 합니다. (Aurora는 잠금을 최소화하려고 노력했습니다)

      만약, 테이블이 오래 잠길 수 밖에 없는 작업을 온라인으로 처리해야만 한다면, percona tool kit에 포함된 pt-online-schema-change 같은 방식을 사용할 수 있습니다.

      같은 레이아웃의 새 테이블을 생성하고, 원본 테이블에 트리거를 생성해서 새 테이블에도 변경 사항이 반영되도록 합니다. 그리고 수십 ms 정도의 인터벌을 주고 1,000 ~ 10,000 건씩 insert ~ select ~ 로 복사합니다. 작업이 끝나면 원본을 삭제하고 새 테이블을 원본 테이블 이름으로 rename 하는 식입니다.

      일단 이 정도를 처리할 수 있다면 운영 상에 큰 문제는 없을 겁니다. ^^

  4. 2019.04.29 17:56  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  5. 구루 2019.07.04 08:56  댓글주소  수정/삭제  댓글쓰기

    Aws에서만 설치가 가능한지 궁금합니다

    저흰 idc 환경이라서요ㅠ

    • BlogIcon 르매 2019.07.04 09:41 신고  댓글주소  수정/삭제

      php CI 기반이라 on-premise 환경에 설치하는 게 어렵지는 않습니다. 다만 개인 사정으로 설치 가이드를 작성할 여유가 없네요. ^^;

      aws 프리티어로 서버 인스턴스 생성하신 후에 copy 해서 옮겨 보시는 건 어떨까요?