実稼働システムの一部としてMySQLの小さなRDSインスタンスがあり、IOPSが提供されている中規模のインスタンスにアップグレードしたい。
昔ながらのDBAとして、「スレーブの追加、マスターへの昇格、クライアントの切り替え」メソッドについては知っていますが、AWSは魔法のワンクリックアップグレードパス、つまり「インスタンスのアップグレード」、「提供されたIOPSの追加」を提供することを約束しています。
テストRDSインスタンスでこれを試してみました。ダウンタイムが長すぎます。私見：小規模から中規模のアップグレードでは約5分、提供されたIOPSへの切り替えでは約30分（!!!）。
回答:
RDSでインスタンスをアップグレードすると、RDSはデータベースを新しいインスタンスに物理的に移行します。これは、おそらく異なる物理ホスト上にあるため、ダウンタイムは避けられません。プロビジョニングされたIOPSへの移行は、データが新しいEBSボリュームに移行されることを意味する可能性があります（また、内部的に、プロビジョニングされたIOPSでEBSボリュームにアクセスできるマシンがあるかどうかに応じて、この変更によりサーバーも新しいインスタンスに移行される可能性があります）そうでないマシンから物理的に分離されているため、別のクラスのネットワークハードウェア上に配置できるため、ダウンタイムは避けられません。
この混乱を回避する方法があるように見えます：リージョン内の別のアベイラビリティーゾーンに見えない、アクセスできない（あなたにとって）レプリカを作成するマルチAZ配置。
OSのパッチ適用やDBインスタンスのスケーリングなどのシステムアップグレードの場合、これらの操作は、自動フェールオーバーの前にスタンバイで最初に適用されます。その結果、可用性への影響は、自動フェールオーバーの完了に必要な時間にのみ制限されます。
これにより、迅速かつシームレスな移行パスが提供されますが、この機能をテストする機会はありません。コンソールの[変更]が表示され、インスタンスをマルチAZに変換できるようになります。おそらく、これにより、インスタンスが複製されるときにI / Oが短時間フリーズするため、当然、この機能を試す前にすべての機能をテストすることをお勧めします。
または、RDSは「スレーブの追加、マスターへの昇格、クライアントの切り替え」操作をエミュレートできる内部メカニズムをサポートします。これにより、ほぼゼロのダウンタイム変換を実現できます。
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を短時間起動し、アクティブ/アクティブマスターツーマスターレプリケーションとして構成することです。構成が完了すると、ダウンタイムなしで、アプリケーショントラフィックを一度に1つのAPPサーバーに切り替えることができます。AWSは、ダウンタイムを回避するためにRDSメンテナンスを発表するたびに、また定期メンテナンス中にこのアプローチを使用します。
https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2
M1 -のorignalマスター
R1 -M1のリードレプリカ
SNAP1 -R1のスナップショット
M2-新しいマスター
M2作成シーケンス：
M1 → R1 → SNAP1 → M2
RDSでSUPER特権を使用できないため— master_data2、M1のオプションでmysqldumpを使用しません。代わりに、R1を起動して、そこからM1のbinlog位置を取得します。次に、R1からスナップショット（SNAP1）を作成し、SNAP1からM2を起動します。
PKの問題を回避するために、次のオフセットを使用して2つの個別の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レプリケーションが正常にセットアップされると、アプリケーションサーバーを1つずつ適切に切り替えることで、ダウンタイムなしでDBのメンテナンスを進める準備ができました。
仕組みの詳細は次のとおりです。
https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2