メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

Amazon Aurora を使用する際のベストプラクティス

このトピックには、Amazon Aurora DB クラスターの使用およびデータ移行のベストプラクティスとオプションに関する情報が含まれます。

接続先の DB インスタンスの決定

次の例に示すように、innodb_read_only グローバル変数をチェックすることにより、Aurora DB クラスターのどの DB インスタンスを接続先にするかを決定できます。

Copy
SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';

innodb_read_only 変数は、Aurora レプリカに接続する場合は ON、プライマリインスタンスに接続する場合は OFF に設定されます。

これは、ワークロードを分散するため、または書き込み操作で適切な接続が使用されているか確認するために、アプリケーションコードにロジックを追加する場合に便利です。

T2 インスタンスの使用

DB インスタンスクラス (db.t2.small または db.t2.medium) を使用する Amazon Aurora インスタンスは、長い時間大量のワークロードをサポートしないアプリケーションに最適です。T2 インスタンスは、適度なベースラインパフォーマンスを実現したり、ワークロードの必要に応じて非常に高いパフォーマンスまでバーストする機能を実現できるように設計されています。常時または一貫して CPU をフルに使用するわけではないが、バーストが必要なことがあるワークロード向けに用意されています。DB インスタンスクラス (db.t2.small および db.t2.medium) は開発サーバーおよびテストサーバー、または他の本稼働以外のサーバーに最適です。T2 インスタンスの詳細については「T2 インスタンス」を参照してください。

DB クラスターのプライマリインスタンスまたは Aurora レプリカに対して、T2 インスタンスクラスを使用する場合は、以下をお勧めします。

  • DB クラスターの DB インスタンスクラスとして T2 インスタンスを使用する場合は、同じ DB インスタンスクラスを DB クラスターのすべてのインスタンスで使用されることをお勧めします。たとえば、プライマリインスタンスに対して db.t2.medium を使用する場合は、Aurora レプリカに対しても db.t2.medium を使用されることをお勧めします。

  • CPU クレジットバランス (CPUCreditBalance) をモニタリングして、持続可能なレベルにあることを確認します。つまり、CPU のクレジットは使用されるのと同じレートで累積されています。

    インスタンス用の CPU クレジットが枯渇した場合、利用可能な CPU がただちにドロップインされ、そのインスタンスに対する読み込みおよび書き込みレイテンシーが増加します。これにより、インスタンス全体のパフォーマンスが大幅に低下します。

    CPU クレジットバランスが持続可能なレベルにない場合、DB インスタンスを、サポートされている R3 DB インスタンスクラス (コンピューティングのスケール) の 1 つを使用するように変更することをお勧めします。

    モニタリングメトリクスの詳細については、「Amazon Aurora DB クラスターのモニタリング」を参照してください。

  • DB クラスターのプライマリインスタンスと Aurora レプリカ間のレプリカラグ (AuroraReplicaLag) をモニタリングします。

    プライマリインスタンスの前に Aurora レプリカの CPU クレジットが不足すると、プライマリインスタンスからの遅延により Aurora レプリカが頻繁に再起動することになります。これは、アプリケーションが DB クラスターの Aurora レプリカ間で分散されている読み取りオペレーションの大きな負荷を維持し、同時にプライマリインスタンスが最小負荷の書き込みオペレーションを維持している場合によくあるシナリオです。

    レプリカラグの増加が持続している場合、DB クラスターの Aurora レプリカの CPU クレジットバランスが枯渇していないことを確認します。

    CPU クレジットバランスが持続可能なレベルにない場合、DB インスタンスを、サポートされている R3 DB インスタンスクラス (コンピューティングのスケール) の 1 つを使用するように変更することをお勧めします。

  • バイナリログが有効な DB クラスターのトランザクションあたりの挿入の数を 100 万以下に維持します。

    DB クラスターの DB クラスターパラメーターグループが binlog_format パラメーターを、OFF 以外の値に設定する場合、DB クラスターに 1,000,000 行以上の挿入を含む大きなトランザクションがあると、DB クラスターにメモリ不足が発生する場合があります。解放可能なメモリ FreeableMemory メトリクスをモニタリングして、DB クラスターが使用できるメモリが不足しているかを確認してから、書き込みオペレーション (VolumeWriteIOPS) メトリクスを確認して、プライマリインスタンスが書き込みオペレーションの大きな負荷を受けているかどうかを調べることができます。この場合、1 つのトランザクションへの挿入の量を 100 万以内に制限するようにアプリケーションを更新する、またはサポートされている R3 DB インスタンスクラス (コンピューティングのスケール) を使用するようにインスタンスを修正することをお勧めします。

AWS Lambda 関数の呼び出し

mysql.lambda_async プロシージャへの呼び出しはストアドプロシージャでラップして、トリガーやクライアントコードなどのさまざまなソースから呼び出せるようにすることをお勧めします。これにより、インピーダンス不整合の問題を回避し、データベースプログラマーが Lambda 関数を簡単に呼び出せるようにすることができます。

Amazon Aurora からの Lambda 関数の呼び出しについて詳しくは、「Amazon Aurora DB クラスターから Lambda 関数を呼び出す」を参照してください。

次の例では、Lambda 関数、Lambda 関数を呼び出すストアドプロシージャ、およびストアドプロシージャを実行して Lambda 関数を呼び出すための呼び出しを示しています。

Lambda 関数

Copy
import boto3 ses = boto3.client('ses') def SES_send_email(event, context): return ses.send_email( Source=event['email_from'], Destination={ 'ToAddresses': [ event['email_to'], ] }, Message={ 'Subject': { 'Data': event['email_subject'] }, 'Body': { 'Text': { 'Data': event['email_body'] } } } )

ストアドプロシージャ

Copy
DROP PROCEDURE IF EXISTS SES_send_email; DELIMITER ;; CREATE PROCEDURE SES_send_email(IN email_from VARCHAR(255), IN email_to VARCHAR(255), IN subject VARCHAR(255), IN body TEXT) LANGUAGE SQL BEGIN CALL mysql.lambda_async( 'arn:aws:lambda:us-west-2:123456789012:function:SES_send_email', CONCAT('{"email_to" : "', email_to, '", "email_from" : "', email_from, '", "email_subject" : "', subject, '", "email_body" : "', body, '"}') ); END ;; DELIMITER ;

ストアドプロシージャを呼び出して Lambda 関数を呼び出す

Copy
mysql> call SES_send_email('example_to@amazon.com', 'example_from@amazon.com', 'Email subject', 'Email content');

Amazon Aurora を使用した MySQL データベースの読み取りスケーリング

MySQL DB インスタンスで Amazon Aurora を使用することで、Amazon Aurora の読み取りスケーリング機能を活用して MySQL DB インスタンスの読み取りワークロードを拡張できます。Aurora を使用して MySQL DB インスタンスの読み取りを拡張するには、Amazon Aurora DB クラスターを作成し、MySQL DB インスタンスのレプリケーションスレーブに指定します。これは、Amazon RDS MySQL DB インスタンス、または Amazon RDS の外部で実行されている MySQL データベースに適用されます。

Amazon Aurora DB クラスターの作成については、「Amazon Aurora DB クラスターの作成」を参照してください。

MySQL DB インスタンスと Amazon Aurora DB クラスターの間でレプリケーションを設定するときは、以下のガイドラインに従ってください。

  • Amazon Aurora DB クラスターを参照するときは、Amazon Aurora DB クラスターのエンドポイントアドレスを使用します。フェイルオーバーが発生すると、Aurora DB クラスターのプライマリインスタンスに昇格された Aurora レプリカで、引き続きこの DB クラスターのエンドポイントアドレスが使用されます。

  • マスターインスタンスの binlog は、それらが Aurora レプリカに適用されていることを確認するまで保持します。このメンテナンスによって、障害発生時にマスターインスタンスを復元できます。

重要

Amazon Aurora DB クラスターがレプリケーションスレーブの場合、レプリケーションが予期せず停止するという既知の問題があります。この場合、CloudWatch のレプリカラグは増加し続けます。この問題が発生した場合は、最新スナップショットから Amazon Aurora DB クラスターを復元し、復元した DB クラスターを新しいレプリケーションスレーブとしてレプリケーションを設定する必要があります。

注記

Amazon Aurora DB クラスターでレプリケーションを開始するために必要なアクセス権限は限定されており、Amazon RDS マスターユーザーは使用できません。このため、Amazon Aurora DB クラスターと MySQL DB インスタンスの間でレプリケーションをセットアップするには、Amazon RDS の mysql.rds_set_external_master コマンドと mysql.rds_start_replication コマンドを使用する必要があります。

外部のマスターインスタンスと Amazon RDS 上の MySQL DB インスタンス間でレプリケーションを開始する

  1. ソース MySQL DB インスタンスを読み取り専用にします。

    Copy
    mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON;
  2. ソース MySQL DB インスタンスで SHOW MASTER STATUS コマンドを実行して、binlog の場所を特定します。次の例のような出力を受け取ります。

    Copy
    File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------
  3. mysqldump を使用して、外部の MySQL DB インスタンスから Amazon Aurora DB クラスターにデータベースをコピーします。非常に大きなデータベースでは、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」の手順を使用することが必要になる場合があります。

    Linux、OS X、Unix の場合:

    Copy
    mysqldump \ --databases <database_name> \ --single-transaction \ --compress \ --order-by-primary \ –u <local_user> \ -p <local_password> | mysql \ --host aurora_cluster_endpoint_address \ –-port 3306 \ –u <RDS_user_name> \ –p <RDS_password>

    Windows の場合:

    Copy
    mysqldump ^ --databases <database_name> ^ --single-transaction ^ --compress ^ --order-by-primary ^ –u <local_user> ^ -p <local_password> | mysql ^ --host aurora_cluster_endpoint_address ^ –-port 3306 ^ –u <RDS_user_name> ^ –p <RDS_password>

    注記

    -p オプションと入力するパスワードの間にスペースがないことを確認します。

    mysql コマンドで、‐‐host‐‐user (-u)‐‐port–p オプションを使用して、Aurora DB クラスターに接続するためのホスト名、ユーザー名、ポート、パスワードを指定します。このホスト名は、Amazon Aurora DB クラスターのエンドポイントの DNS 名 (たとえば mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com) です。エンドポイントの値は、Amazon RDS マネジメントコンソールでクラスターの詳細を確認できます。

  4. もう一度ソース MySQL DB インスタンスを書き込み可能にします。

    Copy
    mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES;

    レプリケーションで使用するバックアップの作成の詳細については、MySQL のドキュメントの「読み取り専用にすることによるマスターまたはスレーブのバックアップ」を参照してください。

  5. Amazon RDS マネジメントコンソールで、ソース MySQL データベースをホストするサーバーの IP アドレスを、Amazon Aurora DB クラスターの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、『Amazon Virtual Private Cloud ユーザーガイド』の「VPC のセキュリティグループ」を参照してください。

    ソース MySQL インスタンスと通信できるようにするために、Amazon Aurora DB クラスターの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Amazon Aurora DB クラスターの IP アドレスを確認するには、host コマンドを使用します。

    Copy
    host <aurora_endpoint_address>

    このホスト名は、Amazon Aurora DB クラスターのエンドポイントからの DNS 名です。

  6. 選択したクライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用される MySQL ユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。次に例を示します。

    Copy
    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  7. 外部の MySQL インスタンスについて、REPLICATION CLIENTREPLICATION SLAVE の特権をレプリケーションユーザーに付与します。たとえば、すべてのデータベースに対する REPLICATION CLIENTREPLICATION SLAVE の特権を、「repl_user」ユーザーに付与するには、次のコマンドを実行します。

    Copy
    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  8. レプリケーションを設定する前に、レプリケーションスレーブになる Aurora DB クラスターの手動スナップショットを作成します。DB クラスターをレプリケーションスレーブとしてレプリケーションを再構築する必要がある場合は、このスナップショットから Aurora DB クラスターを復元でき、MySQL DB インスタンスから新しい Aurora DB クラスターにデータをインポートする必要はありません。

  9. Amazon Aurora DB クラスターをレプリカとして指定します。Amazon Aurora DB クラスターにマスターユーザーとして接続し、mysql.rds_set_external_master コマンドを使用して、ソース MySQL データベースをレプリケーションマスターとして指定します。ステップ 2 で特定したマスターログファイル名とマスターログの場所を使用します。次に例を示します。

    Copy
    CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
  10. Amazon Aurora DB クラスターで、mysql.rds_start_replication コマンドを実行してレプリケーションを開始します。

    Copy
    CALL mysql.rds_start_replication;

ソース MySQL DB インスタンスと Amazon Aurora DB クラスター間のレプリケーションが確立されると、Aurora レプリカを Amazon Aurora DB クラスターに追加できます。その後で、Aurora レプリカに接続してデータの読み取りを拡張できます。Aurora レプリカの作成については、「コンソールを使用した Aurora レプリカの作成」を参照してください。

Amazon Aurora を使用した MySQL データベースの災害対策

MySQL DB インスタンスで Amazon Aurora を使用することで、災害対策用のオフサイトバックアップを作成できます。MySQL DB インスタンスの災害対策に Aurora を使用するには、Amazon Aurora DB クラスターを作成し、MySQL DB インスタンスのレプリケーションスレーブに指定します。これは、Amazon RDS MySQL DB インスタンス、または Amazon RDS の外部で実行されている MySQL データベースに適用されます。

重要

MySQL DB インスタンスと Amazon Aurora DB クラスターの間でレプリケーションを設定する場合、レプリケーションは Amazon RDS によって管理されません。レプリケーションを監視して、レプリケーションが正常に動作していることを確認し、必要な場合は修復する必要があります。

Amazon Aurora DB クラスターを作成して MySQL DB インスタンスのレプリケーションスレーブに指定する方法については、「Amazon Aurora を使用した MySQL データベースの読み取りスケーリング」の手順に従ってください。

わずかなダウンタイムでの MySQL から Amazon Aurora への移行

ライブアプリケーションをサポートする MySQL データベースから Amazon Aurora DB クラスターにデータをインポートするときは、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」で説明されている手順を使用することで、Aurora にデータを移行するためにデータに対するサービスを中断する時間を短縮できます。この手順は特に、ネットワーク経由で AWS に渡されるデータの量を最小限に抑えることによってインポートのコストを削減できるため、非常に大きなデータベースを操作する場合に役立ちます。

この手順では、データベースのデータのコピーを Amazon EC2 インスタンスに送信し、そのデータを新しい Amazon RDS MySQL DB インスタンスにインポートするステップを示します。Amazon Aurora は MySQL と互換性があるため、ターゲット Amazon RDS MySQL DB インスタンスの代わりに Amazon Aurora DB クラスターを使用することができます。