TIL: 2017.11.07

Development / AWS / MySQL / TIL / AWS DMS / AWS RDS

  • 대용량 MySQL 마이그레이션기
    • 4TB 정도의 AWS RDS 상의 MariaDB를 AuroraDB로 Reverse-Migration 하려고 함.
    • 예전에 AuroraDB에서 I/O 가격 이슈 때문에 넘어온 적 있음. 이 때에는 2TB 정도 되었기 때문에, mysqldump를 이용해서 전량 덤프 후에, Read Replica화 해서 Sync 맞추고 무중단 이전 했었음. 그런데 용량이 넘 커서 mysqldump에 진짜 진짜 애를 많이 먹었었다. 특히나 MySQL에서 바로 AuroraDB로 가는건 버튼 하나면 되면서, 거꾸로 가는건 너무 개고생을 해야되서 아주 골치아팠었지. (장사꾼놈들..) 그래서 다음부터는 절대로 RDS 안쓰고 자체 EC2에 MySQL 올려서 xtra backup 같은거 쓸 수 있게 해야겠다고 생각했었는데, 결국 Enterprise 규모의 RDB를 내가 직접(그리고 혼자) 운용하는데 한계가 있다는걸 알게 되었고, RDS에 MariaDB로 운용을 하고 있던 중이었음.) MySQL에서 Aurora로 가는건 버튼 하나로 되기 때문에 쉽게 될 줄 알았더니, 개뿔, MariaDB는 또 그게 안되었다. 말이 안된다.
    • 다시 AuroraDB로 가려고 하는 이유는 높은 비용 예측에도 불구하고, (1)관리 이슈 (2)성능 이슈 (3)안정성(특히나 Read Replica Load-Balancer로 쓰고 있는 Maria MaxScale에 대한 불신뢰) 때문이다.
    • AWS DMS를 이용해 Migration 하려고 했는데, 이놈은 Secondary-index나 FK를 모두 빼놓고 마이그레이션 하는 이슈가 있음.
    • 따라서 Index를 포함해 Schema를 그대로 옮겨야 했기에, AWS Schema Conversion Tool을 활용하기로 함.
      • 정말 간만에 본 아주 잘 만들어진 물건. 이렇게 AWS의 노예가 되어가고..
    • 그런데 생각해보니 같은 MySQL Based DB니까 그냥 Schema Only로 mysqldump 하면 되는거였음. 헤헤.
    • Target DB(AuroraDB with MySQL Compatibility)에 고대로 Schema 옮겨 놓고, 다시 AWS DMS를 이용해 마이그레이션 하려고 했더니.. 아차, DMS는 미친듯이 밀어넣는 시스템인데, FK가 있으면 어짜피 밀어넣을 수가 없다는걸 깨달음. DMS에서 계속 에러 발생.
    • 결국 다시 mysqldump 후 read replica sync로 가야되나.. 라고 낙담하던 찰나에, MySQL 세팅에서 외래키 제약조건(FOREIGNKEYCHECKS)을 끌 수 있다는 사실을 깨달음.
    • AuroraDB에 붙어서 SET GLOBAL FOREIGN_KEY_CHECKS=0으로 끄려고 했더니, 권한이 없단다. 아, RDS.. 리얼 슈퍼유저야 하나본데.. Parameter Group에도 해당 항목이 없고..
    • 근데 찾아보니 AWS DMS 사용시 'Extra connection attribute'를 사용할 수 있음. Docs
      • MySQL Traget인 경우, 외래키 제약을 끄거나(initstmt=SET FOREIGN_KEY_CHECKS=0) 등등을 할 수 있다.
      • Timezone도 initstmt=SET time_zone=UTC로 변경할 수 있음.
        • 여기서 삽질한게 Docs 설명에 왼쪽 셀에는 time-zone으로 되어있는데 실제로는 time_zone이라고 오른쪽 셀의 예제처럼 써줘야함.
        • 또 Docs에는 시간대를 3~4자라고 해놨길래, KST로 했는데 계속 오류가 나길래 이것 저것 해보다가 Asia/Seoul 형식으로 해줘야함을 깨달음.
      • Docs에는 없지만, 여러 파라미터를 동시에 사용하는 경우에는 ;로 구분한다.
        • e.g. parallelLoadThreads=2; initstmt=SET FOREIGN_KEY_CHECKS=0
      • 좀 이상한 부분은, initstmt=SET FOREIGN_KEY_CHECKS=0도 하고 싶고, initstmt=SET time_zone='Asia/Seoul'도 하고 싶어서 두개를 동시에 쓰면, 맨 뒤에 쓴 문구만 적용되고 앞에 문구는 실제 실행이 안됨. 이것저것 삽질 해보았으나 결국 답을 못찾고, timezone은 나에게 중요한 것이 아니었기 때문에(그리고 어짜피 서버에 이미 기본 Timezone이 UTC+9로 되어 있기 때문에) 그냥 외래키 제약 옵션만 걸고 시작함.
      • 여튼 이 Extra connection attribute를 이용하면 동시에 사용할 쓰레드 숫자 같은것도 제어할 수 있음. 개꿀.
    • 일단 걸어놓았고, 현재까지는 에러 없이 순항 중.
Share on : Twitter, Facebook or Google+