프로덕션 시스템의 일부로 MySQL 소형 RDS 인스턴스가 있으며 제공된 IOPS를 사용하여 중간 인스턴스로 업그레이드하고 싶습니다.
구식 DBA로서 저는 "슬레이브 추가, 마스터로 승격; 클라이언트 전환"방법에 대해 알고 있지만 AWS는 마법의 원 클릭 업그레이드 경로 (예 : "업그레이드 인스턴스", "제공된 IOPS")를 제공 할 것을 약속합니다.
테스트 RDS 인스턴스에서 시도한 가동 중지 시간이 너무 깁니다. IMHO : 중소형 업그레이드의 경우 약 5 분, 제공된 IOPS로 전환하는 경우 30 분 (!!!).
답변:
RDS에서 인스턴스를 업그레이드한다는 것은 RDS가 데이터베이스를 물리적으로 다른 물리적 호스트에서 새로운 인스턴스로 물리적으로 마이그레이션하므로 다운 타임을 피할 수 없다는 것을 의미합니다. 프로비저닝 된 IOPS로 마이그레이션하면 데이터가 새로운 EBS 볼륨으로 마이그레이션 될 것입니다 (그리고 내부적으로 프로비저닝 된 IOPS로 EBS 볼륨에 액세스 할 수있는 머신이 그렇지 않은 시스템과 물리적으로 분리되어 다른 종류의 네트워크 하드웨어에있을 수 있으므로 다운 타임을 다시 피할 수 없습니다.
이 중단을 피할 수있는 방법이 있습니다. 다중 AZ 배포 : 리전 내의 다른 가용 영역에 보이지 않고 액세스 할 수없는 (사용자에게) 복제본을 만듭니다.
OS 패치 또는 DB 인스턴스 스케일링과 같은 시스템 업그레이드의 경우 이러한 작업은 자동 장애 조치 전에 대기에서 먼저 적용됩니다. 결과적으로, 가용성 영향은 자동 장애 조치가 완료되는 데 필요한 시간으로 만 제한됩니다.
즉 해야 내가이 기능을 테스트 할 기회가 없었어요 불구하고, 신속하고 원활한 마이그레이션 경로를 제공한다. 콘솔의 "수정"은 인스턴스를 다중 AZ로 변환 할 수 있도록 나타납니다. 아마도 인스턴스가 복제 될 때 I / O가 일시 정지 될 수 있으므로이 기능을 모두 테스트하기 전에 테스트하는 것이 좋습니다.
또는 RDS는 "슬레이브 추가; 마스터로 승격; 클라이언트 전환"작업을 에뮬레이션 할 수 있도록하는 내부 메커니즘을 지원하며, 거의 0에 가까운 다운 타임 변환을 달성 할 수 있어야합니다.
http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/
다중 AZ 환경에서도 60-120 초의 가동 중단이 발생합니다. PostgreSQL db.m3.medium에서 db.m3.large로 업그레이드하는 동안 RDS 인스턴스에 반복적으로 충돌하는 경우입니다.
업그레이드 중에 다운 타임을 피하는 것도 가능합니다. 이를 수행하는 방법은 읽기 전용 복제본 스냅 샷에서 새 RDS를 잠깐 시작하여 활성 / 활성 마스터-마스터 복제로 구성하는 것입니다. 일단 구성되면 다운 타임없이 한 번에 하나의 APP 서버로 애플리케이션 트래픽을 전환 할 수 있습니다. AWS는 예정된 유지 관리 중뿐만 아니라 다운 타임을 피하기 위해 AWS가 RDS 유지 관리를 발표 할 때마다이 방법을 사용합니다.
https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2
M1- 오리 그널 마스터
R1 -M1의 읽기 전용 복제본
SNAP1 -R1의 스냅 샷
M2- 새로운 마스터
M2 생성 순서 :
M1 → R1 → SNAP1 → M2
RDS에 대해 SUPER 권한을 사용할 수 없으므로 — master_data2M1 에서 옵션 과 함께 mysqldump를 사용하지 않습니다 . 대신 R1을 시작 하여 M1 의 binlog 위치 를 얻 습니다. 그런 다음 R1에서 스냅 샷 (SNAP1)을 생성 한 다음 SNAP1에서 M2를 시작하십시오.
PK 충돌을 피하기 위해 다음 오프셋으로 두 개의 별도 RDS 파라미터 그룹을 만듭니다.
M1: auto_increment_ increment = 4 and auto_increment_offset = 1
M2: auto_increment_ increment = 4 and auto_increment_offset = 2
M1에서 복제 사용자 생성
GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO
‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;
1. M1에서 R1 생성
-- Connect to the R1 and stop replication
CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position
`mysql> show slave status\G
Master_Log_File: mysql-bin.000622
Exec_Master_Log_Pos: 91355552. R1에서 SNAP1 생성
M1에서 얻은 속성으로 SNAP1에서 M2를 작성하십시오.
M / M 복제 키 충돌을 피하기 위해 M1과 다른 auto_increment_ 오프셋을 사용하여 M2에 파라미터 그룹을 할당
4. M / M 복제 설정
-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master (‘m1.xyxy24.us-east-1.rds.amazonaws.com’, 3306, ‘repl’, ‘mypassword’, ‘mysql-bin.000622, 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
mysql> show master status\G
File: mysql-bin.004444
Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master (‘m2.xyxy24.us-east-1.rds.amazonaws.com’, 3306 , ‘repl’, ‘mypassword’, ‘mysql-bin.004444, 6666622, 0);
CALL mysql.rds_start_replication;5. R1 및 SNAP1은 더 이상 필요하지 않으므로 삭제하십시오.
6. AWS 콘솔을 통해 M2 업그레이드
표준 절차에 따라 필요에 따라 인스턴스를 수정하십시오.
7. M2 로의 원활한 전환 수행
M / M 복제가 성공적으로 설정되면 App 서버를 한 번에 하나씩 정상적으로 전환하여 다운 타임없이 DB 유지 관리를 진행할 수 있습니다.
작동 방식에 대한 자세한 내용은 다음과 같습니다.
https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2