Database > RDS for MySQL > DBインスタンス

DBインスタンス

DBインスタンスは仮想機器とインストールされたMySQLを包括する概念で、 RDS for MySQLが提供するMySQLの単位です。 DBインスタンスのOSに直接アクセスすることはできず、DBインスタンス作成時に入力したポートを介してデータベースにのみアクセスできます。使用できるポート範囲には以下のような制約事項があります。

• 使用できるポート範囲は3306～43306の間です。

DBインスタンスは、顧客が付与する名前と自動的に付与される32バイトのIDで識別されます。 DBインスタンス名は下記のような制約事項があります。

• DBインスタンス名はリージョンごとに一意でなければなりません。
• DBインスタンス名は1～100文字の間の英字、数字、一部の記号(-, _, .)のみ使用でき、最初の文字は英字のみ使用できます。

DBインスタンス作成

下記の設定でDBインスタンスを作成できます。

アベイラビリティゾーン

NHN Cloudは、物理的なハードウェアの問題で生じる障害に備えるため、システム全体を複数のアベイラビリティゾーンに分けています。このアベイラビリティゾーンごとに、ストレージシステム、ネットワークスイッチ、ラック、電源装置がすべて別々に構成されています。1つのアベイラビリティゾーン内で起こる障害は他のアベイラビリティゾーンに影響を与えないため、サービス全体の可用性が高くなります。DBインスタンスを複数のアベイラビリティゾーンに分けて構築すれば、サービスの可用性をさらに高めることができます。複数のアベイラビリティゾーンに分散して作成されたDBインスタンス同士でネットワーク通信が可能で、この時発生するネットワーク使用費用は請求されません。

[注意] すでに作成したDBインスタンスのアベイラビリティゾーンは変更できません。

DBエンジン

以下に明示されたバージョンを使用できます。

バージョン	備考
8.0
MySQL 8.0.36
MySQL 8.0.35
MySQL 8.0.34
MySQL 8.0.33
MySQL 8.0.32
MySQL 8.0.28
MySQL 8.0.23
MySQL 8.0.18
5.7
MySQL 5.7.37
MySQL 5.7.33	外部のバックアップでDBインスタンスを復元できません。
MySQL 5.7.26
MySQL 5.7.19
MySQL 5.7.15
5.6
MySQL 5.6.33	新規DBインスタンスを作成できません。既存DBインスタンスのリードレプリカ作成、復元のみサポートします。

DBエンジンの場合、作成後、コンソールの修正機能でバージョンアップが可能です。 DBエンジンの詳細はDBエンジンで確認できます。

DBインスタンスタイプ

DBインスタンスはタイプごとに異なるCPUコア数とメモリ容量を持っています。 DBインスタンス作成時、データベースのワークロードに応じて適切なDBインスタンスタイプを選択する必要があります。

タイプ	説明
m2	CPUとメモリをバランスよく設定したタイプです。
c2	CPUのパフォーマンスを高く設定したインスタンスタイプです。
r2	他のリソースに比べてメモリの使用量が多い場合に使用できます。
x1	高スペックのCPUとメモリをサポートするタイプです。高性能が必要なサービスやアプリケーションに使用します。

作成済みのDBインスタンスのタイプはコンソールから簡単に変更できます。

[注意] 作成済みのDBインスタンスのタイプを変更すると、DBインスタンスが終了するため、多少のダウンタイムが発生します。

データストレージ

データストレージにデータベースのデータファイルを保存します。DBインスタンスは、HDD、SSDの2種類のデータストレージタイプをサポートします。データストレージの種類によって性能と価格が異なるため、データベースのワークロードに応じて適切なタイプを選択する必要があります。データストレージは20GB～2TBで作成できます。

[注意] すでに作成したDBインスタンスのデータストレージタイプは変更できません。

[参考] データストレージを2TB以上使用する場合は、NHN Cloudサポートに連絡してください。

以下の作業は、データストレージのI/O使用率が高くなるため、進行中にDBインスタンスの性能が低下する可能性があります。

• 単一DBインスタンスのバックアップ
• 単一DBインスタンスの高可用性構成
• リードレプリカの作成
• リードレプリカの再構築
• 予備マスターの再構築
• 特定の時点への復元
• 単一のDBインスタンスでバックアップした後、オブジェクトストレージにバックアップファイルをエクスポート

高可用性

高可用性DBインスタンスは、可用性とデータの耐久性を高め、障害許容が可能なデータベースを提供します。高可用性DBインスタンスはマスター、予備マスターで構成され、異なる可用性領域に作成されます。予備マスターは障害に備えたDBインスタンスで、普段は使用できません。高可用性DBインスタンスの場合、予備マスターでバックアップが行われるため、バックアップによる性能低下を回避できます。高可用性DBインスタンスが提供する様々な機能は高可用性DBインスタンスで確認できます。

ネットワーク

DBインスタンスに接続するVPCサブネットを選択する必要があります。同じサブネットに接続されたComputeサービスのインスタンス間では、別途のFloating IPなしで通信することができ、ネットワークトラフィックに対する費用が請求されません。 DBインスタンスは基本的にすべてのネットワークアクセスを遮断するため、接続を希望する場合は、DBセキュリティグループを適用する必要があります。

[注意] 作成済みのDBインスタンスのサブネットは変更できません。

Floating IP

外部からDBインスタンスにアクセスするには、Floating IPをDBインスタンスに接続する必要があります。Internet Gatewayが接続されたサブネットを接続する場合のみFloating IPを作成できます。Floating IPは使用と同時に課金され、これとは別にFloating IPを介したインターネット方向のトラフィックが発生する場合は別途課金されます。

パラメータグループ

パラメータグループは、DBインスタンスにインストールされたデータベースを設定できるパラメータの集合です。DBインスタンス生成時に必ず一つのパラメータグループを選択しなければなりません。パラメータグループは、作成後も自由に変更できます。パラメータグループの詳しい説明はパラメータグループの項目を参照してください。

DBセキュリティグループ

DBセキュリティグループは、外部からの侵入に備えて接続を制限するために使用します。送受信トラフィックに対して特定のポート範囲あるいはデータベースポートに対してアクセスを許可できます。DBインスタンスに複数のDBセキュリティグループを適用できます。DBセキュリティグループの詳しい説明はDBセキュリティグループを参照してください。

バックアップ

DBインスタンスのデータベースを定期的にバックアップするように設定したり、コンソールから好きなタイミングでバックアップを作成できます。バックアップが実行されている間、パフォーマンスの低下が発生する場合があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによる性能低下を望まない場合は、高可用性構成を使用するか、以前バックアップ以降のデータの増分のみをバックアップすることができ、読み取りレプリカでバックアップを実行できます。バックアップファイルは内部オブジェクトストレージに保存され、バックアップ容量に応じて課金されます。必要に応じて、NHN Cloudのユーザーオブジェクトストレージにエクスポートできます。予期せぬ障害に備えるため、定期的にバックアップを行うように設定することを推奨します。バックアップの詳細については、バックアップと復元を参照してください。

基本通知

DBインスタンス作成時、基本通知を設定できます。基本通知を設定すると、{{DBインスタンス名}-defaultという名前で新しい通知グループが作成され、下記の通知項目が自動で設定されます。基本通知として作成された通知グループは自由に修正、削除できます。通知グループについての詳しい説明は通知グループを参照してください。

項目	比較方法	しきい値	持続時間
CPU使用率	>=	80%	5分
Storageの空き容量	<=	5,120MB	5分
Database Connection Status	<=	0	0分
Storage使用量	>=	95%	5分
ストレージ障害	<=	0	0分
Connection Ratio	>=	85%	5分
メモリ使用量	>=	90%	5分
Slow Query	>=	60 counts/min	5分

削除保護

削除保護を有効にすると、誤ってDBインスタンスが削除されないように保護できます。

DBインスタンスリスト

コンソールで作成されたDBインスタンスを確認できます。レプリケーショングループ単位でまとめて見たり、個別DBインスタンスで見ることができます。

❶ DBインスタンス画面モードを変更できます。 ❷ボタンをクリックして、グループ内に属するDBインスタンスを展開したり、折りたたむことができます。 ❸最近収集されたモニタリング指標を表示します。 ❹現在の状態を見ることができます。 ❺進行中の作業がある場合、スピナーが表示されます。

DBインスタンスの状態は下記のような値で構成され、ユーザーの行為と現在の状態によって変更されます。

状態	説明
BEFORE_CREATE	作成前
AVAILABLE	使用可能
STORAGE_FULL	容量不足
FAIL_TO_CREATE	作成失敗
FAIL_TO_CONNECT	接続失敗
REPLICATION_STOP	複製中断
FAILOVER	フェイルオーバー完了
SHUTDOWN	停止した

変更できる検索条件は次のとおりです。

❶パラメータ変更事項適用が必要なDBインスタンスをフィルタリング条件で検索できます。

DBインスタンスの詳細

DBインスタンスを選択すると、詳細情報を見ることができます。

❶接続情報のドメインをクリックすると、IPアドレスを確認できるポップアップが表示されます。 ❷ DBセキュリティグループをクリックすると、DBセキュリティルールを確認できるポップアップが表示されます。 ❸パラメータグループをクリックすると、パラメータを確認できる画面に移動します。 ❹マウスでドラッグ＆ドロップして詳細情報パネルの高さを調整できます。 ❺詳細情報パネルの高さをあらかじめ指定した高さに調整できます。

接続情報

DBインスタンス作成時に内部ドメインを発行します。内部ドメインは、ユーザーのVPCサブネットに属するIPアドレスを指します。高可用性DBインスタンスの場合、フェイルオーバーで予備マスターが新しいマスターに変更されても内部ドメインは変更されません。したがって、特別な理由がなければ、アプリケーションの接続情報は必ず内部ドメインを利用する必要があります。

Floating IPを作成した場合、外部ドメインを追加で発行します。外部ドメインはFloating IPのアドレスを指します。外部ドメインまたはFloating IPは外部からアクセスが可能なので、DBセキュリティグループのルールを適切に設定してDBインスタンスを保護する必要があります。

ログ

DBインスタンスのログタブでは、各種ログファイルの閲覧や、ダウンロードを行うことができます。ログファイルは下記のように決められた設定でローテーションされます。一部のログファイルは、パラメータグループで有効または無効にできます。

項目	ローテーション設定	変更するかどうか	関連パラメータ
error.log	100MB 10個	固定
slow_query.log	100MB 40個	固定	slow_query_log
general_log.log	100MB 40個	固定	general_log
server_audit.log	20MB 30個	変更可能	server_audit_logging server_audit_file_rotations
mysql-bin.xxxxxx	5日	変更可能	binlog_expire_logs_seconds (8.Xバージョン) expire_logs_days (5.Xバージョン)

❶ ログ表示をクリックすると、ログファイルの内容を確認できるポップアップ画面が表示されます。最大65,535Bytesのログを確認できます。 ❷ インポートをクリックすると、DBインスタンスのログファイルをダウンロードするようにリクエストします。 ❸ダウンロードの準備が整うと、ダウンロードボタンが表示されます。クリックすると、ログをダウンロードします。

[注意] インポートをクリックすると、約5分間、ログファイルがバックアップストレージにアップロードされ、ログファイルのサイズ分だけバックアップストレージの容量が課金されます。 ダウンロードをクリックすると、ログファイルのサイズ分だけインターネットトラフィックが課金されます。

❹バイナリログ(binary log)の場合、2つの形式でダウンロードできます。インポートをクリックすると、バイナリログの形式を選択できるポップアップ画面が表示されます。

❺ mysqlbinlogユーティリティを利用してバイナリログ(binary log)をSQLファイルに変換してダウンロードする場合は選択します。

DBスキーマ&ユーザー

DBインスタンスのDBスキーマ＆ユーザータブでは、データベースに作成されたスキーマとユーザーの照会及び制御を行うことができます。

DBスキーマの作成

❶ 作成をクリックすると、DBスキーマの名前を入力できるポップアップウィンドウが表示されます。 ❷ DBスキーマ名を入力した後、確認をクリックしてDBスキーマを作成することができます。

DBスキーマ名には下記のような制約事項があります。

• 1～64文字の間のアルファベット、数字、_のみ使用でき、最初の文字は英字のみ使用できます。
• information_schema, performance_schema, db_helper, sys, mysql, rds_maintenanceはDBスキーマ名として使用できません。

作成されたDBスキーマの名前は修正できません。

DBスキーマの削除

❶削除するDBスキーマを選択し、ドロップダウンメニューをクリックします。 ❷ 削除メニューをクリックすると、削除確認ポップアップ画面が表示されます。確認をクリックして削除をリクエストできます。

ユーザーの作成

❶ +作成をクリックすると、ユーザー追加ポップアップ画面が表示されます。 ❷ユーザーIDを入力します。

ユーザーIDには以下のような制約があります。

• 1～32文字の間の文字でなければなりません。
• mysql.session, mysql.sys, mysql.infoschema, sqlgw, admin, etladm, alertman, prom, rds_admin, rds_mha, rds_replはユーザーIDとして使用できません。

❸ Passwordを入力します。 ❹接続を許可するHost IPを入力します。%文字を利用すると、許可するHost IPを範囲として指定できます。例えば、1.1.1.1.1.%は、1.1.1.0~1.1.1.255の間のすべてのIPを意味します。 ❺ユーザーに付与する権限を選択します。付与できる権限と説明は次のとおりです。

READ * 照会権限を持っています。

GRANT SELECT, SHOW VIEW, PROCESS, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO '{user_id}'@'{host}';
GRANT SELECT ON `mysql`.* TO '{user_id}'@'{host}';
GRANT SELECT, EXECUTE ON `sys`.* TO '{user_id}'@'{host}';
GRANT SELECT ON `performance_schema`.* TO '{user_id}'@'{host}';

CRUD * READ権限を含み、データを変更する権限を持っています。

GRANT INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE ON *.* TO '{user_id}'@'{host}';

DDL * CRUD権限を含み、DDLクエリを実行する権限を持っています。

GRANT CREATE, DROP, INDEX, ALTER, CREATE VIEW, REFERENCES, EVENT, ALTER ROUTINE, CREATE ROUTINE, TRIGGER, RELOAD ON *.* TO '{user_id}'@'{host}';
GRANT EXECUTE ON `mysql`.* TO '{user_id}'@'{host}';

CUSTOM * 外部データベースのバックアップからDBインスタンスを復元した場合、データベースに存在する全てのユーザーはCUSTOM権限で表現されます。 * CUSTOM権限テンプレートにはどのような権限があるのか分かりません。 * CUSTOM権限テンプレートから他の権限テンプレートに変更した場合、再びCUSTOM権限テンプレートに変更することはできません。

❻ユーザー認証に適用するプラグインを選択します。選択できるバージョン別プラグインは次のとおりです。

認証プラグイン	サポートバージョン
mysql_native_password	すべてのバージョン
sha256_password	5.7.33バージョン以上8.0バージョン未満
caching_sha2_password	8.0バージョン以上

❼ DBインスタンスの接続暗号化オプションを選択します。

TLS Option	説明
NONE	暗号化された接続を適用しません。
SSL	暗号化された接続を適用します。
X509	暗号化された接続を適用し、接続時に証明書が必要です。接続に必要な証明書はコンソールからダウンロードできます。

[参考] ユーザー認証プラグインとTLS OptionはMySQL 5.7.33バージョン以上でサポートします。

証明書のダウンロード

ユーザーアカウントのTLS OptionをX509に設定した場合、DBインスタンスに接続するには証明書が必要です。

❶証明書をダウンロードするDBインスタンスを選択します。 ❷ドロップダウンメニューをクリックします。 ❸ 証明書ダウンロードをクリックすると、証明書をダウンロードできるポップアップ画面が表示されます。 ❹ダウンロードするファイルの下部にあるインポートをクリックします。 ❺ダウンロードの準備ができると、ダウンロードボタンが表示されます。クリックすると、証明書ファイルをダウンロードできます。

[注意] インポートをクリックすると、約5分間、証明書ファイルがバックアップストレージにアップロードされ、証明書ファイルのサイズ分だけバックアップストレージ容量が課金されます。 ダウンロードをクリックすると、証明書ファイルのサイズ分だけインターネットトラフィックが課金されます。

ユーザーの修正

❶修正するユーザー行の修正をクリックすると、ユーザー情報を修正できるポップアップ画面が表示されます。 ❷ Passwordを入力しないと変更されません。 ❸ユーザー認証に適用するプラグインを変更するには、必ずPasswordを変更する必要があります。

ユーザーの削除

❶削除するユーザーを選択し、ドロップダウンメニューをクリックします。 ❷ 削除をクリックすると、削除確認ポップアップ画面が表示されます。確認をクリックして削除をリクエストできます。

DBインスタンスの修正

コンソールを通じて作成されたDBインスタンスの様々な項目を簡単に変更できます。変更要求した項目は、順次DBインスタンスに適用されます。適用過程で再起動が必要な場合、すべての変更を適用した後、DBインスタンスを再起動します。変更不可能な項目と再起動が必要な項目は次のとおりです。

項目	変更可否	再起動が必要かどうか
アベイラビリティゾーン	いいえ
DBエンジン	はい	はい
DBインスタンスタイプ	はい	はい
データストレージ種類	いいえ
高可用性の有無	はい	いいえ
Ping間隔	はい	いいえ
名前	はい	いいえ
説明	はい	いいえ
DBポート	はい	はい
VPCサブネット	いいえ
Floating IP	はい	いいえ
パラメータグループ	はい	変更されたパラメータの再起動するかどうかで決定
DBセキュリティグループ	はい	いいえ
バックアップ設定	はい	いいえ
自動ストレージ拡張	はい	いいえ
スキーマ&ユーザー制御	はい	いいえ

高可用性DBインスタンスの場合、再起動が必要な項目の変更がある場合、安定性を高め、瞬断時間を減らすためにフェイルオーバーを利用した再起動機能を提供します。

フェイルオーバーを利用した再起動を使用しない場合は、マスターと予備マスターに変更事項を順次適用した後、DBインスタンスを再起動します。詳細は高可用性DBインスタンスの手動フェイルオーバー項目を参照してください。

DBスキーマ&ユーザー直接制御

RDS for MySQLではDBスキーマとユーザーを簡単に管理できるようにコンソールで管理機能を提供していますが、ユーザーが直接制御できるように設定する機能も提供しています。直接制御を使う場合、現在作成されている全てのユーザーに下記の権限を付与します。

GRANT CREATE,DROP,LOCK TABLES,REFERENCES,EVENT,ALTER,INDEX,INSERT,SELECT,UPDATE,DELETE,CREATE VIEW,SHOW VIEW,CREATE ROUTINE,ALTER ROUTINE,EXECUTE,CREATE USER,PROCESS,RELOAD,REPLICATION SLAVE,REPLICATION CLIENT,SHOW DATABASES, CREATE TEMPORARY TABLES,TRIGGER ON *.* TO '{user_id}'@'{host}' WITH GRANT OPTION;

[直接] コントロールを使用した後、再度使用しないに変更した時の注意点 * 既に付与した権限を回収しません。 この時、コマンドを使用してDBスキーマやユーザーを追加すると、コンソールのデータと整合性が合わなくなる場合があります。 * ユーザーに付与された権限と関係なく、データベースに存在するすべてのユーザーはCUSTOM権限で表現されます。

DBインスタンスOSアップグレード

DBインスタンスOSアップグレードをサポートします。OSのアップグレードにより、セキュリティ脆弱性の解決やOSのEOL(end of life)に対応できます。 OSアップグレードはサービス瞬断が発生するため注意が必要です。高可用性DBインスタンスはフェイルオーバーにより、サービス瞬断を最小限に抑えることができます。

現在のDBインスタンスのOS情報は、DBインスタンスの詳細画面で確認できます。

❶ DBインスタンスのOS情報を確認できます。 ❷ OSがバージョンアップグレード対象である場合、OSバージョンアップグレードボタンが表示されます。

OSバージョンアップグレードは、高可用性構成であるかどうかによって異なります。高可用性の場合は、フェイルオーバーを利用してOSバージョンアップグレードを実行します。高可用性ではない場合は、DBインスタンスを再起動してOSバージョンアップグレードを実行します。

単一DBインスタンスのOSバージョンアップグレードボタンをクリックすると、次のようなポップアップ画面が表示されます。 →

高可用性DBインスタンスのOSバージョンアップグレードボタンをクリックすると、次のようなポップアップ画面が表示されます。詳細については、高可用性DBインスタンスの手動フェイルオーバー項目を参照してください。 →

DBインスタンスの削除

使用しないDBインスタンスは削除できます。マスターを削除すると、そのレプリケーショングループに属する予備マスターとリードレプリケーションも全て削除されます。削除されたDBインスタンスは復旧できないため、重要なDBインスタンスは削除保護設定を有効にすることを推奨します。

バックアップ

障害状況に備えて、DBインスタンスのデータベースを復旧できるように事前に準備できます。必要な時にコンソールでバックアップを実行したり、定期的にバックアップが実行されるように設定できます。詳細はバックアップの項目を参照してください。

復元

バックアップを利用して希望の時点にデータを復元できます。復元時には常に新しいDBインスタンスが作成され、既存のDBインスタンスに復元することはできません。詳細は復元の項目を参照してください。

容量確保

急激な負荷でバイナリログ(binary log)が過剰に生成され、ストレージの容量が不足する場合、コンソールの容量確保機能を利用してバイナリログを削除できます。コンソールで容量確保を選択すると、DBインスタンスのバイナリログを選択できるポップアップ画面が表示されます。バイナリログを選択した後、OKを押して選択した項目より前に生成された全てのバイナリログを削除します。容量確保機能は一時的に容量を確保する機能です。継続して容量が不足する場合は、サービス負荷に合わせてバイナリログの保存期間を設定するか、ストレージのサイズを拡張する必要があります。

[参考] MySQL 5.7バージョン以下ではexpire_logs_days、MySQL 5.8バージョン以上ではbinlog_expire_logs_secondsパラメータでバイナリログ(binary log)の保存期間を設定できます。

[注意] 削除されたバイナリログ(binary log)によっては、特定の時点への復元ができない場合があります。

ストレージサイズ拡張

DBインスタンスのデータストレージサイズを拡張できます。拡張時、DBインスタンスを再起動することなくすぐに適用されます。

自動ストレージ拡張

DBインスタンスのデータストレージサイズを自動的に拡張できます。自動ストレージ拡張を使用すると、データストレージの容量が不足したときに自動的に拡張して、データベースの可用性を維持できます。

自動ストレージ拡張を使用するにはDBインスタンス作成及び修正時に自動ストレージ拡張を有効化に必要があります。

自動ストレージ拡張を有効にすると、3つのオプションを設定できます。 * ストレージ自動拡張条件：ストレージ使用率が設定した 値以上で5分以上続く場合、自動的にストレージを拡張します。 * ストレージ自動拡張最大値：ストレージ自動拡張で拡張できる最大サイズです。 * ストレージ自動拡張クールダウン：ストレージ自動拡張機能が一度実行された後、再び機能が有効になるまでの時間を設定します。

ストレージ自動拡張機能が実行されるときの増加量は、次の値のうち最も大きい値に設定されます。 * 10GB * ストレージサイズの10% * 直前の1時間のデータストレージ使用量の増加分 * クールダウン(時間に換算)

パラメータグループの変更事項適用

DBインスタンスに接続されたパラメータグループの設定が変更されても、この変更はDBインスタンスに自動的に適用されません。DBインスタンスに適用されたパラメータと接続されたパラメータグループの設定が異なる場合、コンソールにパラメータボタンが表示されます。

次のいずれかの方法を使用してDBインスタンスにパラメータグループの変更を適用できます。

❶対象DBインスタンスのパラメータをクリックする。 ❷対象DBインスタンスを選択した後、ドロップダウンメニューのパラメータグループ変更適用メニューをクリックするか、または ❸対象DBインスタンスの基本情報タブでパラメータグループの変更事項の適用をクリックする。

パラメータグループで再起動を必要とするパラメータが変更された場合、変更内容を適用する過程でDBインスタンスが再起動されます。

高可用性DBインスタンスの場合、安定性を高め、瞬断時間を減らすためにフェイルオーバーを利用した再起動機能を提供します。

フェイルオーバーを利用した再起動を使用しない場合は、マスターと予備マスターに変更事項を順次適用した後、DBインスタンスを再起動します。詳細は高可用性DBインスタンスの手動フェイルオーバー項目を参照してください。

オブジェクトストレージにあるバックアップで復元

外部MySQLのバックアップファイルをNHN Cloudのユーザーオブジェクトストレージにアップロードして、RDS for MySQLのDBインスタンスに復元することができます。詳細は、外部MySQLバックアップを利用した復元を参照してください。

バックアップ後、オブジェクトストレージにバックアップファイルをエクスポート

バックアップ後、バックアップファイルをユーザーオブジェクトストレージにエクスポートできます。詳細については、バックアップエクスポート項目を参照してください。

リードレプリカ

読み取り性能を高めるために、読み取り専用に使用できるリードレプリカを作成できます。リードレプリカは1つのマスターに対して最大5台まで作成できます。リードレプリカのリードレプリカは作成できません。

リードレプリカの作成

リードレプリカを作成するには、レプリケーショングループに属するDBインスタンスのうち、テーブルロック使用オプションで作成されたバックアップファイルとバイナリログ(binary log)が必要です。バックアップファイルがない場合、次の順序でバックアップを実行するDBインスタンスを選択します。

❶自動バックアップを設定したリードレプリカ ❷自動バックアップを設定した予備マスター ❸自動バックアップを設定したマスター

条件に合致するDBインスタンスがない場合、リードレプリカ作成リクエストは失敗します。

[注意] リードレプリカ作成時、マスターのI/O性能が通常より低くなることがあります。 バックアップが実行されるDBインスタンスの場合、リードレプリカの作成過程でストレージI/O性能が低下する可能性があります。

[参考] リードレプリカの作成過程で必要なバイナリログ(binary log)サイズ分、オブジェクトストレージ課金が発生する可能性があります。

リードレプリカを作成するには、コンソールで

❶原本DBインスタンスを選択した後、[リードレプリカ作成]をクリックすると

以下の設定でリードレプリカを作成できます。

変更不可項目

リードレプリカを作成する際、下記の項目は原本DBインスタンスの設定に従うため、変更できません。

• DBエンジン
• データストレージの種類
• ユーザーVPCサブネット

リードレプリカリージョン

リードレプリカを作成するリージョンを選択する際、リージョンピアリングをサポートする場合、異なるリージョンに存在するVPC間のリージョンピアリングを接続すると、他のリージョンVPCに属するサブネットにリードレプリカを作成できます。ただし、元のDBインスタンスのリージョンと異なるリージョンを選択すると、レプリケーションの遅延が発生する可能性があり、DBバージョンのアップグレードをサポートしません。

[注意] リージョンピアリングが接続されていても、ルート設定が正しくない場合、リードレプリカの作成に失敗したり、レプリケーションが中断されることがあります。

アベイラビリティゾーン

リードレプリカのアベイラビリティゾーンを選択します。詳しい説明はアベイラビリティゾーン項目を参照してください。

DBインスタンスタイプ

リードレプリカは、マスターと同じ仕様またはより高い仕様で作成することを推奨します。低い仕様で作成すると、複製遅延が発生する場合があります。

データストレージサイズ

原本DBインスタンスと同じサイズで作成することを推奨します。サイズを小さく設定する場合、データストレージ容量不足で複製プロセスが中断される場合があります。

弹性IP

リードレプリカのFloating IPを使用するかどうかを選択します。詳しい説明はFloating IPの項目を参照してください。

パラメータグループ

リードレプリカのパラメータグループを選択する際、レプリケーション関連設定を変更する必要がない場合は、元のDBインスタンスと同じパラメータグループを選択することを推奨します。パラメータグループの詳しい説明はパラメータグループ項目を参照してください。

DBセキュリティグループ

リードレプリカに適用するDBセキュリティグループを選択します。レプリケーションに必要なルールは自動的に適用されるため、DBセキュリティグループに別途レプリケーション関連ルールを追加する必要はありません。 DBセキュリティグループの詳しい説明はDBセキュリティグループの項目を参照してください。

リードレプリカの昇格

マスターとの複製関係を解除して、リードレプリカを独立したマスターに転換する過程を昇格といいます。昇格したマスターは独立したDBインスタンスとして動作します。昇格を希望するリードレプリカとマスターの間に複製遅延が存在する場合、その遅延が解決されるまで昇格が行われません。一度昇格されたDBインスタンスは、以前の複製関係に戻すことはできません。

[注意] マスターDBインスタンスの状態が異常な場合は、昇格作業を進めることができません。

[参考] リードレプリカが位置するリージョンと同じリージョンのコンソールを通じて昇格作業を行うことができます。

リードレプリカの強制昇格

マスターや原本リージョンの状態に関係なく、リードレプリカの現在時点のデータに基づいて強制昇格を行います。複製遅延がある場合、データ損失が発生する可能性があります。したがって、リードレプリカを緊急にサービスに投入しなければならない状況でない限り、この機能の使用は推奨しません。

リードレプリカの複製中断

リードレプリカは、さまざまな理由で複製が中断されることがあります。リードレプリカの状態が複製中断の場合、すぐに原因を確認して正常化する必要があります。複製中断状態が長時間続く場合、複製ディレイが長くなります。正常化に必要なバイナリログ(binary log)がない場合、リードレプリカを再構築する必要があります。複製が中断した原因はリードレプリカでSHOW SLAVE STATUSコマンドを使用して確認できます。Last_Errnoの値が1062の場、以下のProcedureをエラーが消えるまで呼び出せます。

mysql> CALL mysql.tcrds_repl_skip_repl_error();

リードレプリカの再構築

リードレプリカの複製問題を解決できない場合、再構築を通じて正常な状態に復元できます。この過程でリードレプリカの全てのデータベースを削除し、マスターデータベースを基盤に新たに再構築します。再構築中は、リードレプリカは使用できません。リードレプリカを再構築するには、レプリケーショングループに属するDBインスタンスのうち、テーブルロック使用オプションで作成されたバックアップファイルとバイナリログ(binary log)が必要です。バックアップファイルがない場合、動作及び注意事項はリードレプリカの作成の項目を参照してください。

[参考] 再構築後も接続情報(ドメイン、IP)は変更されません。

DBインスタンスの再起動

MySQLを再起動したり、高可用性DBインスタンスを手動でフェイルオーバーしたい場合、DBインスタンスを再起動できます。再起動時間を最小化するため、サービス負荷が低い時間帯に行うことをお勧めします。高可用性DBインスタンスの場合、フェイルオーバーを利用した再起動を使用しない場合、予備マスターを先に再起動した後、マスターを再起動します。フェイルオーバー機能を利用した再起動の場合、手動フェイルオーバー項目を参照してください。

DBインスタンスを再起動するには、コンソールで

❶再起動を希望するDBインスタンスを選択した後、ドロップダウンメニューからDBインスタンスの再起動メニューをクリックします。

DBインスタンスの強制再起動

DBインスタンスのMySQLが正常に動作しない場合、強制的に再起動できます。強制再起動の場合、MySQLにSIGTERMコマンドを実行して正常終了するのを10分間待ちます。10分以内にMySQLが正常終了したら、仮想マシンを再起動します。10分以内に正常終了しない場合、仮想マシンを強制的に再起動します。仮想マシンが強制的に再起動されると、作業中の一部のトランザクションが失われる可能性があり、データボリュームが破損して復旧が不可能になる可能性があります。強制再起動後、DBインスタンスの状態が使用可能な状態に戻らない場合があります。このような状況が発生した場合は、サポートにお問い合わせください。

[注意] データが消失したり、データボリュームが破損する可能性があるため、この機能は緊急かつ不可避な状況以外では使用を控えてください。

[参考] 高可用性DBインスタンスの場合、強制再起動はできません。

DBインスタンスを強制的に再起動するには、コンソールで

❶強制再起動を希望するDBインスタンスを選択した後、ドロップダウンメニューからDBインスタンス強制再起動メニューをクリックします。

削除保護設定の変更

削除保護を有効にすると、誤ってDBインスタンスが削除されないように保護できます。削除保護を無効化するまで、そのDBインスタンスを削除できません。削除保護設定を変更するには

❶削除保護設定を変更したいDBインスタンスを選択した後、ドロップダウンメニューから削除保護設定変更メニューをクリックすると、ポップアップウィンドウが表示されます。

❷削除保護設定を変更した後、確認をクリックします。

高可用性DBインスタンス

高可用性DBインスタンスは可用性とデータ耐久性を増加させ、障害許容が可能なデータベースを提供します。高可用性DBインスタンスはマスター、予備マスターで構成され、異なるアベイラビリティゾーンに作成されます。予備マスターは障害に備えたDBインスタンスで、通常は使用できません。高可用性DBインスタンスの場合、予備マスターでバックアップが行われます。

[参考] 高可用性DBインスタンスの場合、MySQLクエリ文を使用して他のDBインスタンスまたは外部MySQLのMasterから強制的に複製するように設定すると、高可用性および一部の機能が正常に動作しません。

障害検出

予備マスターには障害を検出するためのプロセスが存在し、定期的にマスターの状態を検出します。このような検出周期をPing間隔と呼び、4回連続状態チェックに失敗した場合、フェイルオーバーを実行します。Ping間隔が短いほど障害に敏感に反応し、Ping間隔が長いほど障害に鈍感に反応します。サービス負荷に合わせて適切なPing間隔を設定することが重要です。

[参考] マスターのストレージ使用量がいっぱいになると、高可用性監視プロセスが障害として検出し、フェイルオーバーを実行するので注意してください。

自動フェイルオーバー

予備マスターでマスターの状態チェックに4回連続失敗した場合、マスターがサービスを提供できないと判断し、自動的にフェイルオーバーを実行します。スプリットブレイン防止のため、障害が発生したマスターに割り当てられたすべてのユーザーセキュリティグループの接続を解除して外部からの接続を遮断し、予備マスターがマスターの役割を代行します。接続のための内部ドメインのA recordは障害が発生したマスターから予備マスターに変更されるので、アプリケーションの変更は必要ありません。フェイルオーバーが完了すると、障害が発生したマスターの種類はフェイルオーバーが発生したマスターに、予備マスターの種類はマスターに変更されます。フェイルオーバーが発生したマスターを復旧または再構築するまでフェイルオーバーは実行されません。昇格されたマスターは、フェイルオーバーが発生したマスターのすべての自動バックアップを継承します。フェイルオーバーの過程でマスターが変更されると、バイナリログがすべて削除されるため、既存のバックアップを利用した時点復元はサポートされません。昇格されたマスターで新規にバックアップが行われた時点から時点復元を行うことができます。

[参考] 高可用性機能はドメインに基づいているため、接続をしようとするクライアントがDNSサーバーに接続できないネットワーク環境の場合、ドメインを介してDBインスタンスに接続することができず、フェイルオーバー発生時、正常な接続ができません。 内部ドメインのA recordの変更が反映されるのに約3秒程度かかります。所要時間は、接続を試みるクライアント環境のDNS Cacheポリシーによって異なる場合があります。

[注意] マスターと予備マスター間のバイナリログ(binary log)のposition numberの値が100,000,000,000以上差がある場合、フェイルオーバーが行われません。

フェイルオーバーが発生したマスター

障害が発生してフェイルオーバーが発生したマスターをフェイルオーバーが発生したマスターといいます。フェイルオーバーが発生したマスターの自動バックアップは行われず、フェイルオーバーが発生したマスターの復旧、再構築、分離、削除を除く他のすべての機能は実行できません。

フェイルオーバーが発生したマスターの復旧

フェイルオーバーの過程でデータの整合性が崩れず、障害が発生した時点から復旧を試みる時点までバイナリログ(binary log)が失われなければフェイルオーバーが発生したマスターと昇格したマスターを再び高可用性構成で復旧できます。フェイルオーバーが発生したマスターのデータベースをそのまま昇格されたマスターと複製関係を再設定するため、データの整合性が崩れたり復旧に必要なバイナリログ(binary log)が失われた場合、復旧は失敗します。フェイルオーバーが発生したマスターの復旧に失敗した場合、再構築を通じて再び高可用性機能を有効にできます。

[参考] 2023年4月11日以前にフェイルオーバーが発生したDBインスタンスの場合、復旧をサポートしません。

フェイルオーバーされたマスターを復旧するには、コンソールで

❶復旧を希望するフェイルオーバーされたマスターを選択した後、ドロップダウンメニューからフェイルオーバーされたマスターの復旧メニューをクリックします。

フェイルオーバーが発生したマスターの再構築

フェイルオーバーが発生したマスターの復旧に失敗した場合、再構築を利用して再び高可用性機能を有効にできます。再構築は復旧とは異なり、フェイルオーバーが発生したマスターのデータベースを全て削除し、昇格したマスターのデータベースを基に再構築します。バックアップファイルがない場合、次の順序でバックアップを実行するDBインスタンスを選択します。

❶自動バックアップを設定したリードレプリカ ❷自動バックアップを設定したマスター

条件に合うDBインスタンスがない場合、フェイルオーバーされたマスターの再構築要求は失敗します。

[注意] マスターのデータベースサイズに比例して、フェイルオーバーされたマスターの再構築時間が長くなる場合があります。 バックアップが実行されるDBインスタンスの場合、フェイルオーバーされたマスター再構築の過程で、ストレージI/O性能が低下する可能性があります。

[参考] フェイルオーバーされたマスターの再構築過程に必要なバイナリログ(binary log)サイズ分、バックアップストレージの課金が発生する可能性があります。

フェイルオーバーされたマスターを再構築するには、コンソールで

❶再構築を希望するフェイルオーバーされたマスターを選択した後、ドロップダウンメニューからフェイルオーバーされたマスターの再構築メニューをクリックします。

フェイルオーバーされたマスターの分離

フェイルオーバーされたマスターの復旧に失敗してデータ補正が必要な場合、フェイルオーバーされたマスターを分離して高可用性機能を無効にできます。分離されたマスターと昇格されたマスター間の複製関係が切断され、それぞれ一般的なDBインスタンスとして動作します。分離された後は、元の構成に復旧することはできません。

フェイルオーバーされたマスターを分離するには、コンソールで

❶分離を希望するフェイルオーバーされたマスターを選択した後、ドロップダウンメニューからフェイルオーバーされたマスター分離メニューをクリックします。

フェイルオーバーが発生したマスター分離

フェイルオーバーが発生したマスターの復旧に失敗してデータ補正が必要な場合、そのマスターを分離して高可用性機能を無効にできます。分離されたマスターと昇格されたマスター間の複製関係が切断され、それぞれ一般DBインスタンスとして動作します。分離後は既存の構成に戻せません。

手動フェイルオーバー

高可用性DBインスタンスの場合、再起動を伴う作業を実行すると、フェイルオーバーを利用した再起動を行うかどうかを選択でき、その作業は次のとおりです。

• DBインスタンスの再起動
• 再起動が必要な項目の変更
• 再起動が必要なパラメータの変更を適用
• ハイパーバイザーの点検のためのDBインスタンスのマイグレーション

フェイルオーバーを利用した再起動を行うと、予備マスターを先に再起動します。その後、フェイルオーバーにより予備マスターをマスターに昇格させ、既存のマスターは予備マスターの役割をすることになります。昇格時に接続のための内部ドメインのA recordはマスターから予備マスターに変更されるので、アプリケーションの変更は必要ありません。昇格されたマスターは、以前のマスターのすべての自動バックアップを継承します。フェイルオーバーの過程でマスターが変更され、バイナリログ(binary log)がすべて削除されるため、既存のバックアップを利用した時点復元はサポートしません。昇格されたマスターで新規にバックアップが行われた時点から時点復元を行うことができます。

[注意] 予備マスターとレプリケーショングループに含まれるリードレプリカのSeconds_Behind_Masterの値が1以上の場合、製遅遅延が発生したものとみなし、手動フェイルオーバーは失敗します。負荷が少ない時間に手動フェイルオーバーを行うことを推奨します。レプリケーション遅延による再起動の失敗は、イベント画面で確認できます。

フェイルオーバーを利用した再起動時、次の項目を追加的に選択して安定性を高めることができます。

現在の時点のバックアップを実行

フェイルオーバーの過程でバイナリログ(binary log)がすべて削除されるため、フェイルオーバーを利用した再起動が完了した後、すぐに手動バックアップを行うことができます。

フェイルオーバーの手動制御

予備マスターに変更事項を先に適用した後、その推移を観察したり、正確な時間にフェイルオーバーを実行したい場合、コンソールでフェイルオーバーのタイミングを直接制御できます。フェイルオーバー手動制御を選択すると、予備マスターが再起動された後、❶コンソールにフェイルオーバーボタンが表示されます。このボタンをクリックするとフェイルオーバーが実行され、最大5日間実行を待機できます。5日以内にフェイルオーバーを実行しない場合、その作業は自動的にキャンセルされます。

[注意] フェイルオーバーを待機している間は、自動フェイルオーバーは行われません。

複製遅延解消待機

複製遅延解消待機オプションを有効にすると、予備マスターとレプリケーショングループに含まれるリードレプリカの複製遅延がなくなるまで待機できます。

書き込み負荷遮断

複製遅延を解消する間、書き込み負荷を追加的に遮断する選択が可能です。書き込み負荷を遮断すると、フェイルオーバーを実行する直前にマスターが読み取り専用モードに切り替わり、すべての変更クエリが失敗するように設定されます。

高可用性の一時停止

一時的な作業による接続中断や大量の負荷が予想される状況で、一時的に高可用性機能を停止できます。高可用性機能が一時停止されると、障害を検出しないため、フェイルオーバーを実行しません。高可用性機能が一時停止した状態で再起動が必要な作業を実行しても一時停止された高可用性機能が再開されません。高可用性機能が一時停止するとデータ複製は正常に行われず、障害が検出されないため、長時間一時停止状態に維持することは推奨しません。

予備マスター再構築

ネットワークの切断、誤ったFEDERATEDエンジンの使用、他のマスターからの複製設定など、さまざまな原因で予備マスター複製が中断されることがあります。複製中断状態の予備マスターは自動フェイルオーバーが実行されません。予備マスターの複製中断を解決するには予備マスターを再構築する必要があります。予備マスターの再構築時には予備マスターのデータベースをすべて削除し、マスターのデータベースを基に再構築します。この過程で再構築に必要なバックアップファイルがマスターデータベースに存在しない場合、マスターでバックアップが行われ、バックアップによる性能低下が発生する可能性があります。

MySQL Procedure

RDS for MySQLはユーザーに利便性を提供するため、ユーザーアカウントで制限されるいくつかの機能を実行するプロシージャを独自に提供しています。

tcrds_active_process

• ProcesslistでSleep状態ではなくACTIVE状態のクエリを照会します。
• 実行時間が古い順に出力され、クエリ内容(SQL)は100桁までしか出力されません。

mysql> CALL mysql.tcrds_active_process();

tcrds_process_kill

• 特定のプロセスを強制終了します。
• 終了するプロセスIDはinformation_schema.processlistで確認でき、tcrds_active_processとtcrds_current_lockプロシージャを使ってプロセスの情報を確認できます。

mysql> CALL mysql.tcrds_process_kill(processlist_id );

tcrds_current_lock

• 現在ロックを待っているプロセスとロックを占有しているプロセス情報を確認します。
• (w)カラム情報がロックを獲得するために待機しているプロセス情報。
• (B)カラム情報がロックを占有しているプロセス情報。
• ロックを占有しているプロセスを強制終了するには、(B)PROCESS列を確認した後、call tcrds_process_kill(process_id)を実行します。

mysql> CALL mysql.tcrds_current_lock();

tcrds_repl_changemaster

• 複製を利用して外部MySQL DBをNHN Cloud RDSにインポートする時使います。
• NHN Cloud RDSの複製構成は、コンソールの複製の作成で行うことができます。

mysql> CALL mysql.tcrds_repl_changemaster (master_instance_ip, master_instance_port, user_id_for_replication, password_for_replication_user, MASTER_LOG_FILE, MASTER_LOG_POS);

• パラメータの説明
• master_instance_ip:複製対象(Master)サーバーのIP
• master_instance_port:複製対象(Master)サーバーのMySQLポート
• user_id_for_replication:複製対象(Master)サーバーのMySQLに接続する複製用アカウント
• password_for_replication_user:複製用アカウントパスワード
• MASTER_LOG_FILE:複製対象(Master)のbinary logファイル名
• MASTER_LOG_POS:複製対象(Master)のbinary logポジション

ex) call mysql.tcrds_repl_changemaster('10.162.1.1',10000,'db_repl','password','mysql-bin.000001',4);

[注意]複製用アカウントが複製対象(Master) MySQLに作成されている必要があります。

tcrds_repl_init

• MySQL複製情報を初期化します。

mysql> CALL mysql.tcrds_repl_init();

tcrds_repl_slave_stop

• MySQLの複製を止めます。

mysql> CALL mysql.tcrds_repl_slave_stop();

tcrds_repl_slave_start

• MySQLの複製を開始します。

mysql> CALL mysql.tcrds_repl_slave_start();

tcrds_repl_skip_repl_error

• SQL_SLAVE_SKIP_COUNTER=1を実行します。次のようなDuplicate keyエラー発生時、tcrds_repl_skip_repl_errorプロシージャを実行すると、複製エラーを解決できます。
• MySQL error code 1062: 'Duplicate entry ? for key ?'

mysql> CALL mysql.tcrds_repl_skip_repl_error();

tcrds_repl_next_changemaster

• Masterの次のバイナリ(binary log)ログを読めるように複製情報を変更します。
• 次のような複製エラーが発生した場合、tcrds_repl_next_changemasterプロシージャを実行すると、複製エラーを解決できます。

例) MySQL error code 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG): Got fatal error from master when reading data from binary log

mysql> CALL mysql.tcrds_repl_next_changemaster();

tcrds_innodb_monitor_reset

• information_schema.INNODB_METRICSテーブルのcounterを0にリセットするinnodb_monitor_reset variablesを実行するプロシージャです。
• SET GLOBAL innodb_monitor_reset = '{counter-name|module_name|pattern|all}';クエリを実行します。
• innodb_monitor_enable、innodb_monitor_disableはRDSパラメータで提供します。

mysql> CALL mysql.tcrds_innodb_monitor_reset('{counter-name|module_name|pattern|all}');

ex) CALL mysql.tcrds_innodb_monitor_reset('dml_reads');
CALL mysql.tcrds_innodb_monitor_reset('module_dml');

tcrds_innodb_monitor_reset_all

• counter値をリセットするinnodb_monitor_reset_all variablesを実行するプロシージャです。
• innodb_monitor_reset_allを使用するには、counterがdisable状態である必要があります。
• SET GLOBAL innodb_monitor_reset_all = '{counter-name|module_name|pattern|all}';クエリを実行します。

mysql> CALL mysql.tcrds_innodb_monitor_reset_all('{counter-name|module_name|pattern|all}');

tcrds_foreign_key_checks

• foreign key制約条件をチェックする'foreign_key_checks'変数を制御するプロシージャです。
• SET GLOBAL foreign_key_checks ='ON|OFF';クエリを実行します。

mysql> CALL mysql.tcrds_foreign_key_checks('{0|1|'OFF'|'ON'}');

データマイグレーション

• RDSはmysqldumpを利用してNHN Cloud RDSの外部にデータをエクスポートしたり、外部からインポートできます。
• mysqldumpユーティリティはMySQLをインストールした時、基本的に提供されます。

mysqldumpを利用してエクスポート

• NHN Cloud RDSのインスタンスを準備して使用します。
• エクスポートするデータを保存する外部インスタンス、もしくはローカルクライアントがインストールされたコンピュータの容量が十分に確保されていることを確認します。
• NHN Cloudの外部にデータをエクスポートする場合、Floating IPを作成してデータをエクスポートするRDSインスタンスに接続します。
• 下記のmysqldumpコマンドを使って外部にデータをエクスポートします。

ファイルにエクスポートする場合

mysqldump -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}

NHN Cloud RDS外部のMySQL DBにエクスポートする場合

mysqldump -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port}

mysqldumpを利用してインポート

• データをインポートするNHN Cloud RDS外部のDBを準備します。
• インポートするNHN Cloud RDSインスタンスの容量が十分か確認します。
• Floating IPを作成してNHN Cloud RDSインスタンスに接続します。
• 下記のmysqldumpコマンドで外部からデータをインポートします。

mysqldump -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port} --single-transaction --set-gtid-purged=off --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port}

データのインポート中にERROR 1227エラーが発生した場合

• ERROR 1227エラーはmysqldumpファイルの保存されたオブジェクト(トリガー、ビュー、関数またはイベント)にDEFINERが定義されている時に発生します。これを解決するためには、mysqldumpファイルでDEFINER部分を削除してください。

データのインポート中にERROR 1418エラーが発生する場合

• ERROR 1418エラーはmysqldumpファイルの関数宣言にNO SQL、READS SQL DATA, DETERMINISTICがなく、バイナリログが有効な状態の時に発生します。
• 詳細についてはThe Binary Log MySQL文書を参照してください。
• これを解決するためには、mysqldumpファイルを適用するDBインスタンスのlog_bin_trust_function_creatorsパラメータの値を1に変更する必要があります。

複製を利用してエクスポート

• 複製を利用してNHN Cloud RDSのデータを外部DBにエクスポートできます。
• 外部DBのバージョンは、NHN Cloud RDSのバージョンと同じか、それより新しいバージョンである必要があります。
• データをエクスポートするNHN Cloud RDS MasterまたはRead Only Slaveインスタンスを準備します。
• Floating IPを生成してデータをエクスポートするNHN Cloud RDSインスタンスに接続します。
• 下記のコマンドでNHN Cloud RDSインスタンスからデータをファイルにエクスポートします。
• Master RDSインスタンスからエクスポートする場合

mysqldump -h{rds_master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}

• Read Only Slave RDSインスタンスからエクスポートする場合

mysqldump -h{rds_read_only_slave_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}

• バックアップされたファイルを開いて、コメントに書かれたMASTER_LOG_FILE及びMASTER_LOG_POSを別に記録します。
• NHN Cloud RDSインスタンスからデータをバックアップする外部ローカルクライアントまたはDBがインストールされたコンピュータの容量が十分であることを確認します。
• 外部DBのmy.cnf(Windowsの場合my.ini)ファイルに下記のようなオプションを追加します。
• server-idの場合、NHN Cloud RDSインスタンスのパラメータ項目のserver-idと違う値を入力します。

...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...

• 外部DBを再起動します。
• バックアップされたファイルを下記のコマンドで外部DBに入力します。

mysql -h{external_db_host} -u{exteranl_db_id} -p{external_db_password} --port={exteranl_db_port} < {local_path_and_file_name}

• NHN Cloud RDSインスタンスで複製に使用するアカウントを作成します。
• 新しく複製を設定する前に、もしかしたら存在するかもしれない既存のレプリケーション情報を初期化するために下記のクエリを実行します。この時、RESET SLAVEを実行すると、既存の複製情報が初期化されます。

STOP SLAVE;

RESET SLAVE;

• 複製に使うアカウント情報と、先ほど別に記録しておいたMASTER_LOG_FILEとMASTER_LOG_POSを使って外部DBに下記のようにクエリを実行します。

CHANGE MASTER TO master_host = '{rds_master_instance_floating_ip}', master_user='{user_id_for_replication}', master_password='{password_forreplication_user}', master_port ={rds_master_instance_port}, master_log_file ='{MASTER_LOG_FILE}', master_log_pos = {MASTER_LOG_POS};

START SLAVE;

• 外部DBとNHN Cloud RDSインスタンスの原本データが同じになったら、外部DBにSTOP SLAVEコマンドを利用して複製を終了します。

複製を利用してインポート

• 複製を利用して外部DBをNHN Cloud RDSにインポートできます。
• NHN Cloud RDSのバージョンは外部DBのバージョンと同じか、それより新しいバージョンでなければなりません。
• データをエクスポートする外部MySQLインスタンスに接続します。
• 下記のコマンドで外部MySQLインスタンスからデータをバックアップします。
• 外部MySQLインスタンス(マスター)からインポートする場合

mysqldump -h{master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}

• 外部MySQLインスタンス(スレーブ)からインポートする場合

mysqldump -h{slave_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}

• バックアップされたファイルを開いて、コメントのMASTER_LOG_FILE及びMASTER_LOG_POSを別に記録します。
• NHN Cloud RDSインスタンスからデータをバックアップするクライアントやコンピュータの容量が十分か確認します。
• 外部DBのmy.cnf(Winodwsの場合はmy.ini)ファイルに下記のオプションを追加します。
• server-idの場合、NHN Cloud RDSインスタンスのパラメータ項目のserver-idと異なる値を入力します。

...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...

• 外部DBを再起動します。
• 外部ネットワークからインポート(import)すると時間がかかる場合があるので、内部NHN Cloud Imageを作成してバックアップファイルをコピーした後、NHN Cloudにインポートすることを推奨します。
• バックアップされたファイルを下記のコマンドでNHN Cloud RDSに入力します。
• 複製構成はDNSをサポートしていないため、IPに変換して実行します。

mysql -h{rds_master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} < {local_path_and_file_name}

• 外部MySQLインスタンスで複製に使うアカウントを作成します。

mysql> CREATE USER 'user_id_for_replication'@'{external_db_host}' IDENTIFIED BY '<password_forreplication_user>';
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'user_id_for_replication'@'{external_db_host}';

• レプリケーションに使うアカウント情報と先に記録しておいたMASTER_LOG_FILE, MASTER_LOG_POSを利用してNHN Cloud RDSに次のようにクエリを実行します。

mysql> call mysql.tcrds_repl_changemaster ('rds_master_instance_floating_ip',rds_master_instance_port,'user_id_for_replication','password_forreplication_user','MASTER_LOG_FILE',MASTER_LOG_POS );

• レプリケーションを開始するには下記のプロシージャを実行します。

mysql> call mysql.tcrds_repl_slave_start;

• 外部DBとNHN Cloud RDSインスタンスの元データが同じになったら、下記のコマンドを利用して複製を終了します。

mysql> call mysql.tcrds_repl_init();

付録

付録1. ハイパーバイザメンテナンスのためのDBインスタンスマイグレーションガイド

NHN Cloudは周期的にDBインスタンスのハイパーバイザソフトウェアをアップデートしてセキュリティと安定性を向上させています。 メンテナンス対象ハイパーバイザで起動中のDBインスタンスは、マイグレーションを通してメンテナンスが完了したハイパーバイザに移動する必要があります。

DBインスタンスのマイグレーションはNHN Cloudコンソールで開始できます。 DB構成に応じて特定DBインスタンスを選択してマイグレーションする時、関連するDBインスタンス(例えばSlaveインスタンス)もメンテナンス対象の場合は一緒にマイグレーションを進行します。 下記のガイドに従ってコンソールにあるマイグレーション機能を利用してください。 メンテナンス対象に指定されたDBインスタンスがあるプロジェクトに移動します。

1. メンテナンス対象DBインスタンスを確認します。

名前の横にマイグレーションボタンがあるDBインスタンスがメンテナンス対象のインスタンスです。

マイグレーションボタンにマウスオーバーすると、メンテナンス日程の詳細を確認できます。

2. メンテナンス対象DBインスタンスに接続中のアプリケーションソフトウェアを終了する必要があります。

DBに接続しているサービスに影響を与えないように、適切な措置を取ってください。 やむを得ずサービスに影響を与えてしまう時は、NHN Cloudサポートに連絡してくだされば、適切な措置を案内いたします。

3. メンテナンス対象DBインスタンスを選択してマイグレーションボタンをクリックし、DBインスタンスマイグレーションの確認ウィンドウが表示されたら確認ボタンをクリックします。

4. DBインスタンスのマイグレーションが終わるまで待機します。

DBインスタンスの状態が変更されない場合は「更新」を行ってください。

DBインスタンスのマイグレーション中は何も操作ができません。 DBインスタンスのマイグレーションが正常に完了しなかった場合、自動的に管理者に報告され、NHN Cloudから別途連絡いたします。

付録2. RDSを利用してFederated Storage Engine使用するときの構成ガイド

Federated Storage Engineを使用する場合、次を考慮する必要があります。

ローカルノードとしてRDSを利用する構成の場合

• リモートノードへの送信を許可する設定が必要です。
• DBセキュリティグループでルールを追加できます。
• 詳細については、 DBセキュリティグループ項目を参照してください。
• ローカルノード役割のRDSにRead Only Slaveを追加した構成で使用する場合は、パラメータのreplicate-ignore-tableにfederated設定されたテーブル名を指定する必要があります。
• Read Only Slaveを構成する場合、 federatedテーブルも複製され、MasterとRead Only Slaveがリモートノードを一緒に見ます。
• この場合、Masterに行ったデータ入力がfederated設定によってリモートノードにも行われ、Read Only Slaveでも同様に同じ入力が行われ、重複キーエラーなどによるレプリケーション中断が発生することがあります。
• Read Only Slaveがfederatedテーブルを複製しないようにreplicate-ignore-tableに設定する必要があります。

リモートノードとしてRDSを利用する構成の場合

• ローカルノードでの受信を許可する設定が必要です。
• DBセキュリティグループでルールを追加できます。
• 詳細については、 DBセキュリティグループ項目を参照してください。