web-dev-qa-db-ja.com

本番RDSインスタンスをアップグレードする最適な方法は何ですか？

MySQLの小規模なRDSインスタンスを本番システムの一部として使用しており、IOPSが提供された中規模のインスタンスにアップグレードしたいと考えています。

昔ながらのDBAとして、「スレーブの追加、マスターへの昇格、クライアントの切り替え」方法について知っていますが、AWSは、ワンクリックで魔法のアップグレードパスを提供することを約束します。

テストRDSインスタンスでこれを試したところ、ダウンタイムが長すぎる、IMHO：小規模から中規模のアップグレードでは約5分、提供されたIOPSへの切り替えでは30分（!!!）。

  • これは正常な動作ですか？
  • ダウンタイムなしで本番RDSでアップグレードを実行する方法はありますか？
  • 「停止、スナップショットの作成、スナップショットから大きなインスタンスへの復元」の方法をお勧めしますか？
mysqlamazon-rds
35
Vitaly

RDSでインスタンスをアップグレードするということは、RDSがデータベースを新しいインスタンスに物理的に移行することを意味します。おそらく別の物理ホスト上にあるため、ダウンタイムは避けられません。プロビジョニングされたIOPSへの移行は、データが新しいEBSボリュームに移行されることを意味します（この変更により、プロビジョニングされたIOPSでEBSボリュームにアクセスできるマシンが内部にあるかどうかに応じて、サーバーも新しいインスタンスに移行される可能性があります物理的に隔離されていないマシンから分離されているため、別のクラスのネットワークハードウェア上に存在する可能性があるため、ダウンタイムは避けられません。

この混乱を回避する方法があるようです。マルチAZ配置では、リージョン内の別のアベイラビリティーゾーンに非表示でアクセスできない（ユーザーには）レプリカが作成されます。

OSパッチやDBインスタンスのスケーリングなどのシステムアップグレードの場合、これらの操作は、自動フェイルオーバーの前に、スタンバイで最初に適用されます。その結果、可用性への影響は、自動フェイルオーバーが完了するのに必要な時間のみに制限されます。

— http://aws.Amazon.com/rds/multi-az/

これはすべきです迅速かつシームレスな移行パスを提供しますが、私はこの機能をテストする機会がありませんでした。コンソールの「変更」は、インスタンスをマルチAZに変換できるように見えます。おそらく、これによりインスタンスのクローンが作成されるときにI/Oが短時間フリーズするため、この機能を試す前にすべての機能をテストすることをお勧めします。

または、RDSは、「スレーブの追加、マスターへの昇格、クライアントの切り替え」操作をエミュレートできる内部メカニズムをサポートしています。これにより、ダウンタイムに近い変換を実現できます。

  • 目的のインスタンスクラスを使用して、データベースの実際のRDSリードレプリカを作成します
  • レプリカがオンラインになり、マスターと同期されるのを待ちます
  • レプリカの構成を変更して、プロビジョニングされたIOPSを追加する
  • レプリカがオンラインになり、マスターと同期されるのを待ちます
  • サードパーティのツールを使用して、両方のシステムに同じデータがあることを確認します
  • アプリケーションを古いマスターから切断します
  • マスターとレプリカで一致するbinlog座標を確認して、すべてのアプリケーションの書き込みが複製されていることを確認します
  • RDSの新しいレプリカで「リードレプリカの昇格」を使用してシステムを分割する
  • アプリケーションを新しいマスターに接続する

http://aws.Amazon.com/about-aws/whats-new/2012/10/11/Amazon-rds-mysql-rr-promotion/

38
Michael - sqlbot

マルチAZ環境でも、 60-120秒の停止が発生します。 これは、アップグレードの実行中にRDSインスタンスに繰り返しアクセスした場合です。 PostgreSQL db.m3.mediumからdb.m3.largeへ。

4
Wayn E

アップグレード中のダウンタイムを回避することも可能です。これを行う方法は、リードレプリカスナップショットから新しいRDSを短時間起動し、アクティブ/アクティブマスターからマスターへのレプリケーションとして構成することです。構成が完了すると、ダウンタイムなしで、アプリケーショントラフィックを一度に1つのAPPサーバーに切り替えることができます。 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権限を使用できないため、M1で— master_data2オプションを指定したmysqldumpを使用しません。代わりに、R1を起動してM1のバイナリログ位置を取得します。次に、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: 9135555

2。 R1からSNAP1を作成する

  • M1から取得した属性を使用して、SNAP1からM2を作成します。

  • M1からのauto_increment_オフセットが異なるM2にパラメーターグループを割り当てて、M/Mレプリケーションキーの競合を回避します。

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

3
Dmitriy Royzenberg

これは機能しますが、RDSインスタンスのエンドポイントがアプリケーションで静的エントリとして構成されていないことを確認する必要があります。 RDSを交換すると、エンドポイントが変更されます。

1
Anup Singh