일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 독후감
- 알고리즘
- 삼성역량테스트
- 와썹맨
- 삼성인 아마조니언 되다
- 기술적 채무
- minimum path sum
- Dynamic Programmin
- No Rules Rules
- 블린이
- 프로그래머스
- leetcode
- BFS
- 김태강
- technical debt
- Python
- 나는 아마존에서 미래를 다녔다
- mysql #numa #swap #memory
- 아마조니언
- LongestPalindromicSubstring
- 그거봤어?
- 파이썬
- 동적 프로그래밍
- Envoy
- list of list
- 리트코드
- Unique Paths
- 트리
- 리스트의 리스트
- 규칙없음
- Today
- Total
개발자가 되고 싶은 준개발자
MySQL 데이터베이스 이관 시 고려할 점 본문
DB를 운영하다 보면 서비스 담당 팀의 변경이나 담당 회사의 변경, 서버 노후화로 인한 서버 교체 등의 다양한 이유로 데이터베이스 이관을 하게 된다.
데이터베이스 이관 시에는 다양한 이해관계자들이 함께 협의를 하는 경우가 많다. 이관 전에 DB를 운영하는 사람, 서비스를 담당하는 PM, 이관 후 운영할 사람, 개발자 등이 함께 진행 방향을 논의하게 된다.
논의에 앞서 DBA 입장에서 먼저 확인해 보면 좋은 것들이 있다.
1. 이관할 데이터의 양
먼저 이관할 데이터의 양은 최대한 줄이는 것이 좋다. 대부분의 서비스에서는 로그성으로 쌓기만 하고 데이터 변경은 하지 않는 테이블이 있고, 주로 이런 테이블들의 용량이 크다. 이런 테이블들은 서비스 이관 시에 바로 필요한 데이터가 아닐 수 있기에 이관 우선순위가 떨어진다. 개발팀이나 DBA와의 협의를 통해 서비스에서 필요한 데이터만 이관 시점에 옮기고, 즉시 필요하지 않은 데이터는 이관 시점 전에 미리 옮겨놓거나 이관 후에 천천히 옮기도록 하면 좋다. (물론 필요없는 데이터는 아예 이관하지 않는 것이 가장 좋다.)
2. Database 버전
다음으로 데이터 베이스 버전이다. 같은 버전 간의 이관은 문제가 되지 않으나, 버전 차이가 많이 나는 데이터베이스 간의 이간은 고려해야 할 점이 많다. 버전별로 지원함수, 지원 툴 등이 다르기 때문에 미리 일정 데이터를 옮기거나 스키마만 덤프를 떠서 import해보는 방식으로 버전 차이로 인한 이슈는 없는지 사전에 확인이 필요하다. 만약 사전에 문제가 발견된다면 버전 업그레이드 없이 선이관 한 후에 안정기를 가지고 운영을 하다가, 업그레이드를 추후에 진행하는 것도 방법이다.
버전 차이가 나는 DB를 이관해야 한다면 mysql 공식 문서를 참고하여 버전 간 차이가 어떤 것들이 있는지 사전에 확인해 보는 과정도 필요하다.
3. 데이터 백업/ 복구에 걸리는 시간
데이터 백업/복구에 걸리는 시간을 이관할 데이터의 양과 관련이 있다. 이관할 데이터의 양이 결정되면 실제로 데이터 백업과 import를 사전에 진행을 해서, 대략적으로 얼마나 시간이 걸릴지 확인해 본다. 이때 확인한 시간을 근거로 이관시에 서비스 다운을 시키면 얼마의 다운타임이 필요한지 알 수 있다.
4. 방화벽 정책 등 서버 간 접속 가능 여부
마지막으로 데이터 덤프를 전송할 때 필요한 22 port나 db 복제 연결을 위해 3306 포트를 서버 간 열 수 있는지도 사전에 확인이 필요하다. 22 포트를 열수 없다면 데이터 덤프를 전송할 수 없기 때문에, 리모트 서버에서 3306 포트로 접속해서 dump를 생성하거나(이 경우 네트워크를 타고 덤프 파일이 생성되므로 느릴 수 있다) 다른 방법을 찾아야 한다.
위의 사항들을 파악하면 PM에게 이관 방식에 대해 옵션을 제공하고, 서비스 다운타임을 가져갈지 무중단으로 가져갈지 결정할 수 있다.
서비스 다운 타임 없이 무중단으로 가는 것이 가장 편하나 특정한 경우에는 중단 시간 없이 이관하는 것이 불가능한 경우가 있다.
1.버전 차이가 큰 경우
예를 들어 5.5 버전에서 8.0 버전으로 이관을 해야 한다면 DBA 입장에서는 큰 부담이다. 이관 후에 5.5->5.6->5.7->8.0으로 업그레이드를 3번 거쳐야 한다. 물론 시간을 가지고 천천히 단계를 나누어 진행할 수 있으면 괜찮다. 그러나 8.0버전으로 빠른 이관이 필요하다면 서비스 다운타임을 가지고 mysqldump를 떠서 8.0 버전이 설치된 신규 DB 에 dump를 import하는 것이 가장 편한 방법이다.
2.데이터 복제가 불가능한 경우
상용 서비스에서는 실시간으로 데이터가 쌓이기 때문에 dump로 대부분의 데이터를 옮겨 놓고, 실시간으로 쌓이는 데이터는 신규 DB에서 기존 DB로 복제 연결을 하여 복제를 통해 데이터를 따라잡아야 한다.
그러나 회사 정책 상의 이유 등으로 신규 DB에서 기존 DB로 연결이 불가한 상황이라면 실시간으로 쌓이는 데이터를 동기화할 방법이 없다. 이럴 때는 실시간으로 데이터가 쌓이지 않도록 서비스를 내리고, dump를 떠서 옮기는 방법 밖에 없다.
모든 협의가 끝나면 세부 사항을 확인하면서 이관을 진행하면 된다.
'MySQL > mysql' 카테고리의 다른 글
[MySQL] PK, unique key 컬럼 선정 방법 (aka. 복제 지연 예방 방법) (0) | 2023.07.17 |
---|---|
[MySQL] Delete 쿼리 하나로 수십시간의 복제 지연 발생 원인 분석 (0) | 2023.05.04 |
[MySQL] swap 사용률 낮추기 위해 NUMA 정책 interleave로 바꾸기 (0) | 2023.02.23 |
[mysql] DDL 지연 현상 해결 방법 (0) | 2023.01.03 |
mysql 쿼리 튜닝 기본 (0) | 2022.12.14 |