# Amazon RDS for MariaDB
Amazon RDS は、DB インスタンス用に複数のバージョンの MariaDB をサポートしています。サポートされているバージョンの詳細については、「[Amazon RDS の MariaDB のバージョン](MariaDB.Concepts.VersionMgmt.md)」を参照してください。
MariaDB DB を作成するには、Amazon RDS の管理ツールまたはインターフェイスを使用します。これで、Amazon RDS ツールを使用して DB インスタンスの管理アクションを実行できるようになります。これには、以下のようなアクションが含まれます。
+ DB インスタンスの再設定またはサイズ変更
+ DB インスタンスへの接続の許可
+ バックアップまたはスナップショットからの作成と復元
+ マルチ AZ セカンダリの作成
+ リードレプリカの作成
+ DB インスタンスのパフォーマンスのモニタリング
DB インスタンスでデータを保存したり、またはアクセスするには、標準の MariaDB のユーティリティとアプリケーションを使用します。
MariaDB がすべての AWS リージョン で利用可能になりました。AWS リージョン の詳細については、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
Amazon RDS for MariaDB 用の Amazon RDS を使用して、HIPAA 準拠のアプリケーションを構築できます。AWS との事業提携契約 (BAA) に基づいて、保護されるべき医療情報 (PHI) を含め、医療関連の情報を保存できます。詳細については、「[HIPAA コンプライアンス](https://aws.amazon.com/compliance/hipaa-compliance/)」を参照してください。AWS対象範囲内のサービスは、サードパーティーの監査人によって十分に評価され、認定、コンプライアンスの証明、または Authority to Operate (ATO) が与えられます。詳細については、[コンプライアンスプログラムによる対象範囲内の AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)を参照してください。
DB インスタンスを作成する前に、「[Amazon RDS 環境のセットアップ](CHAP_SettingUp.md)」の手順を完了してください。DB インスタンスを作成すると、RDS マスターユーザーは DBA 権限を取得します。ただし、いくつかの制限があります。このアカウントは、追加のデータベースアカウントの作成などの管理タスクに使用します。
以下を作成することができます。
+ DB インスタンス
+ DB スナップショット
+ ポイントインタイムの復元
+ 自動バックアップ
+ 手動バックアップ
Amazon VPC に基づいて Virtual Private Cloud (VPC) 内で MariaDB を実行する DB インスタンスを使用できます。また、さまざまなオプションを有効にして、MariaDB DB インスタンスに機能を追加することもできます。Amazon RDS は、可用性の高いフェイルオーバーソリューションとして MariaDB のマルチ AZ 配置をサポートしています。
**重要**
マネージドサービスエクスペリエンスを提供するうえで、Amazon RDS は DB インスタンスへのシェルアクセスを提供していません。また、高度な特権を必要とする、特定のシステムプロシージャやテーブルへのアクセスも制限しています。データベースへのアクセスには、mysql クライアントなどの標準の SQL クライアントアプリケーションを使用します。ただし、Telnet またはセキュアシェル (SSH) を使用してホストに直接アクセスすることはできません。
**Topics**
+ [Amazon RDS での MariaDB 機能のサポート](MariaDB.Concepts.FeatureSupport.md)
+ [Amazon RDS の MariaDB のバージョン](MariaDB.Concepts.VersionMgmt.md)
+ [MariaDB DB インスタンスへの接続](USER_ConnectToMariaDBInstance.md)
+ [MariaDB DB インスタンス接続の保護](securing-mariadb-connections.md)
+ [Amazon RDS Optimized Reads による RDS for MariaDB のクエリパフォーマンスの向上](rds-optimized-reads-mariadb.md)
+ [Amazon RDS Optimized Writes for MariaDB による書き込みパフォーマンスの向上](rds-optimized-writes-mariadb.md)
+ [MariaDB DB エンジンのアップグレード](USER_UpgradeDBInstance.MariaDB.md)
+ [MariaDB DB スナップショットエンジンバージョンのアップグレード](mariadb-upgrade-snapshot.md)
+ [Amazon RDS for MariaDB DB インスタンスへのデータのインポート](MariaDB.Procedural.Importing.md)
+ [Amazon RDS での MariaDB のレプリケーションの使用](USER_MariaDB.Replication.md)
+ [MariaDB データベースエンジンのオプション](Appendix.MariaDB.Options.md)
+ [MariaDB のパラメータ](Appendix.MariaDB.Parameters.md)
+ [MySQL DB スナップショットから MariaDB DB インスタンスへのデータ移行](USER_Migrate_MariaDB.md)
+ [Amazon RDS SQL での MariaDB リファレンス](Appendix.MariaDB.SQLRef.md)
+ [MariaDB DB インスタンスのローカルタイムゾーン](MariaDB.Concepts.LocalTimeZone.md)
+ [Amazon RDS for MySQL の既知の問題と制限](CHAP_MariaDB.Limitations.md)
# Amazon RDS での MariaDB 機能のサポート
RDS for MariaDB は MariaDB のほとんどの特徴と機能をサポートしています。一部の機能には、制限付きのサポートまたは制限された特権があります。
[[What's New with Database?](https://aws.amazon.com/about-aws/whats-new/database/)] (データベースの新機能) ページで新しい Amazon RDS 機能をフィルタリングできます。[**製品**] で [**Amazon RDS**] を選択します。その後、**MariaDB 2023** などのキーワードを使用して検索します。
**注記**
以下のリストは完全なものではありません。
Amazon RDS での MariaDB 機能のサポートの詳細については、以下のトピックを参照してください。
**トピック**
+ [Amazon RDS の MariaDB でサポートされているストレージエンジン](MariaDB.Concepts.Storage.md)
+ [Amazon RDS での MariaDB のキャッシュウォームアップ](MariaDB.Concepts.XtraDBCacheWarming.md)
+ [Amazon RDS でサポートされていない MariaDB の機能](MariaDB.Concepts.FeatureNonSupport.md)
## Amazon RDS for MariaDB のメジャーバージョンでの MariaDB 機能のサポート
次のセクションでは、Amazon RDS for MariaDB のメジャーバージョンでの MariaDB 機能のサポートに関する情報について説明しています。
**Topics**
+ [Amazon RDS での MariaDB 11.8 のサポート](#MariaDB.Concepts.FeatureSupport.11-8)
+ [Amazon RDS での MariaDB 11.4 のサポート](#MariaDB.Concepts.FeatureSupport.11-4)
+ [Amazon RDS での MariaDB 10.11 のサポート](#MariaDB.Concepts.FeatureSupport.10-11)
+ [Amazon RDS での MariaDB 10.6 のサポート](#MariaDB.Concepts.FeatureSupport.10-6)
+ [Amazon RDS での MariaDB 10.5 のサポート](#MariaDB.Concepts.FeatureSupport.10-5)
+ [Amazon RDS での MariaDB 10.4 のサポート](#MariaDB.Concepts.FeatureSupport.10-4)
Amazon RDS for MariaDB のサポートされているマイナーバージョンについては、「[Amazon RDS の MariaDB のバージョン](MariaDB.Concepts.VersionMgmt.md)」を参照してください。
### Amazon RDS での MariaDB 11.8 のサポート
Amazon RDS は、MariaDB バージョン 11.8 以降を実行する DB インスタンスで以下の新しい機能をサポートしています。
**注記**
MariaDB 11.8 では、`require_secure_transport` のデフォルト値は `1` になり、安全な SSL/TLS 接続が必要です。非セキュア接続が必要な場合は、`0` に設定します。
+ **パラメータの新しいデフォルト値** – `require_secure_transport` パラメータのデフォルト値が `0` から `1` に変更され、デフォルトで安全なトランスポート接続が強制されます。詳細については、「[Amazon RDS 上の MariaDB DB インスタンスへのすべての接続に SSL/TLS を要求する](mariadb-ssl-connections.require-ssl.md)」を参照してください。
+ **ベクトルサポート** – MariaDB Vector を使用して、AI で生成されたベクトルを MariaDB に直接保存および検索できます。この機能では、次のシステム変数が導入されています。
+ 変数 [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_distance](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_distance) は、MHNSW ベクトルインデックス作成のデフォルトの距離メトリクスを指定します。
+ 変数 [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_m](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_m) は、MHNSW ベクトルインデックス作成の `M` パラメータのデフォルト値を定義します。
+ 変数 [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_ef_search](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_ef_search) は、ベクトルインデックス検索の結果候補の最小数を定義します。
+ 変数 [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_max_cache_size](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_max_cache_size) は、1 つの MHNSW ベクトルインデックスキャッシュの上限を設定します。
+ **一時ファイルサイズ制限** – RDS Maria DB 11.8 パラメータグループで使用できる 2 つのシステム変数を使用して、作成されたディスク一時ファイルとテーブルのサイズを制限できるようになりました。
+ 変数 [https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_session_space_usage-system-variable](https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_session_space_usage-system-variable) は、ユーザーあたりの一時スペース許容量を制限します。
+ 変数 [https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_total_space_usage-system-variable](https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_total_space_usage-system-variable) は、すべてのユーザーの一時スペースの許容量を制限します。
+ **一時テーブルスペース管理** – 一時テーブルスペースは一時テーブルを保存し、データが追加されると拡大します。一時テーブルが削除されても、スペースは自動的に再利用されません。手順 [mysql.rds\$1execute\$1operation](mysql_rds_execute_operation.md) を使用して、一時テーブルスペースを縮小し、ディスク容量を再利用できます。
MariaDB 11.8 のすべての機能と関連ドキュメントのリストについては、MariaDB ウェブサイトで「[Changes and improvements in MariaDB 11.8](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-8/)」および「[Release notes - MariaDB 11.8 series](https://mariadb.com/kb/en/release-notes-mariadb-11-8-series/)」を参照してください。
サポートされない機能の一覧については、「[Amazon RDS でサポートされていない MariaDB の機能](MariaDB.Concepts.FeatureNonSupport.md)」を参照してください。
### Amazon RDS での MariaDB 11.4 のサポート
Amazon RDS は、MariaDB バージョン 11.4 以降を実行する DB インスタンスで以下の新しい機能をサポートしています。
+ **暗号化ライブラリ** – RDS for MariaDB は OpenSSL を FIPS 140-3 認定の AWS Libcrypto (AWS-LC) に置き換えました。
+ **Simple Password Check プラグイン** – MariaDB の [Simple Password Check プラグイン](https://mariadb.com/kb/en/simple-password-check-plugin/)を使用して、パスワードに特定のタイプの文字が少なくとも特定の数だけ含まれているかどうかを確認できます。詳細については、「[RDS for MariaDB のパスワード検証プラグインの使用](MariaDB.Concepts.PasswordValidationPlugins.md)」を参照してください。
+ **Cracklib Password Check プラグイン** – MariaDB の [Cracklib Password Check プラグイン](https://mariadb.com/kb/en/cracklib-password-check-plugin/)を使用して、新しいパスワードの強度を確認できます。詳細については、「[RDS for MariaDB のパスワード検証プラグインの使用](MariaDB.Concepts.PasswordValidationPlugins.md)」を参照してください。
+ **InnoDB の機能強化** — これらの機能には、次の項目があります。
+ 変更バッファが削除されました。詳細については、「[InnoDB Change Buffering](https://mariadb.com/kb/en/innodb-change-buffering/)」を参照してください。
+ InnoDB デフラグが削除されました。詳細については、「[InnoDB Defragmentation](https://mariadb.com/kb/en/defragmenting-innodb-tablespaces/#innodb-defragmentation)」を参照してください。
+ **新しい権限** – 管理者ユーザーに `SHOW CREATE ROUTINE` 権限も付与されました。この権限により、被付与者は、他のユーザーが所有するルーチンの `SHOW CREATE` 定義ステートメントを表示できます。詳細については、「[Database Privileges](https://mariadb.com/kb/en/grant/#database-privileges)」を参照してください。
+ **レプリケーションの改善** – MariaDB バージョン 11.4 の DB インスタンスは、バイナリログのインデックス作成をサポートしています。バイナリログファイルごとに GTID インデックスを作成できます。これらのインデックスは、GTID の検索にかかる時間を短縮することで、レプリケーションのパフォーマンスを向上させます。詳細については、「[Binlog Indexing](https://mariadb.com/kb/en/gtid/#binlog-indexing)」を参照してください。
+ **廃止または削除されたパラメータ** — MariaDB バージョン 11.4 の DB インスタンスでは、以下のパラメータが廃止または削除されました。
+ `engine_condition_pushdown` を [optimizer\$1switch](https://mariadb.com/kb/en/optimizer-switch/) から削除
+ [innodb\$1change\$1buffer\$1max\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_change_buffer_max_size)
+ [innodb\$1defragment](https://mariadb.com/kb/en/innodb-system-variables/#innodb_defragment)
+ `TLSv1.0` と `TLSv1.1` を [tls\$1version](https://mariadb.com/kb/en/ssltls-system-variables/#tls_version) から削除
+ **パラメータの新しいデフォルト値** – [innodb\$1undo\$1tablespaces](https://mariadb.com/kb/en/innodb-system-variables/#innodb_undo_tablespaces) パラメータのデフォルト値が `0` から `3` に変更されました。
+ **パラメータの新しい有効な値** – MariaDB バージョン 11.4 の DB インスタンスでは、以下のパラメータに新しい有効な値が追加されました。
+ [binlog\$1row\$1image](https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#binlog_row_image) パラメータの有効な値として `FULL_NODUP` が追加されました。
+ [OLD\$1MODE](https://mariadb.com/kb/en/old-mode/) パラメータの有効な値として `NO_NULL_COLLATION_IDS` が追加されました。
+ **新しいパラメータ** — MariaDB バージョン 11.4 の DB インスタンスでは、以下のパラメータが新しくなります。
+ [transaction\$1isolation](https://mariadb.com/kb/en/server-system-variables/#transaction_isolation) パラメータは [tx\$1isolation](https://mariadb.com/kb/en/server-system-variables/#tx_isolation) パラメータに置き換わります。
+ [transaction\$1read\$1only](https://mariadb.com/kb/en/server-system-variables/#transaction_read_only) パラメータは [tx\$1read\$1only](https://mariadb.com/kb/en/server-system-variables/#tx_read_only) パラメータに置き換わります。
+ [block\$1encryption\$1mode](https://mariadb.com/kb/en/server-system-variables/#block_encryption_mode) パラメータは、[AES\$1ENCRYPT()](https://mariadb.com/kb/en/aes_encrypt/) 関数と [AES\$1DECRYPT()](https://mariadb.com/kb/en/aes_decrypt/) 関数のデフォルトのブロック暗号化モードを定義します。
+ [character\$1set\$1collations](https://mariadb.com/kb/en/server-system-variables/#character_set_collations) は、文字セットのデフォルトの照合順序のオーバーライドを定義します。
+ [binlog\$1gtid\$1index](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index)、[binlog\$1gtid\$1index\$1page\$1size](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index_page_size)、[binlog\$1gtid\$1index\$1span\$1min](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index_span_min) は、バイナリログの GTID インデックスのプロパティを定義します。詳細については、「[Binlog Indexing](https://mariadb.com/kb/en/gtid/#binlog-indexing)」を参照してください。
MariaDB 11.4 のすべての機能と関連ドキュメントのリストについては、MariaDB ウェブサイトで「[Changes and improvements in MariaDB 11.4](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-4/)」および「[Release notes - MariaDB 11.4 series](https://mariadb.com/kb/en/release-notes-mariadb-11-4-series/)」を参照してください。
サポートされない機能の一覧については、「[Amazon RDS でサポートされていない MariaDB の機能](MariaDB.Concepts.FeatureNonSupport.md)」を参照してください。
### Amazon RDS での MariaDB 10.11 のサポート
Amazon RDS は、MariaDB バージョン 10.11 以降を実行する DB インスタンスで以下の新しい機能をサポートしています。
+ **パスワード再利用チェックプラグイン** — MariaDB パスワード再利用チェックプラグインを使用して、ユーザーがパスワードを再利用できないようにしたり、パスワードの保持期間を設定したりできます。詳細については、「[パスワード再利用チェックプラグイン](https://mariadb.com/kb/en/password-reuse-check-plugin/)」を参照してください。
+ **GRANT TO PUBLIC 認可** — サーバーにアクセスできるすべてのユーザーに、権限を付与できます。詳細については、「[GRANT TO PUBLIC](https://mariadb.com/kb/en/grant/#to-public)」を参照してください。
+ **SUPER と READ ONLY ADMIN 権限の分離** — 以前に SUPER 権限を持っていたユーザーも含め、すべてのユーザーから READ ONLY ADMIN 権限を削除できます。
+ **セキュリティ** — MariaDB クライアントのデフォルトとしてオプション `--ssl` を設定できるようになりました。MariaDB は、設定が正しくない場合でも SSL をサイレントに無効にすることがなくなりました。
+ **SQL コマンドと関数** — `SHOW ANALYZE FORMAT=JSON` コマンドと関数 `ROW_NUMBER`、`SFORMAT`、および `RANDOM_BYTES`、`SFORMAT` を使用して、文字列の書式設定を可能にできるようになりました。これはデフォルトで有効になっています。1 つのコマンドでパーティションをテーブルに、テーブルをパーティションに変換できます。`JSON_*()` 関数に関して他にもいくつかの改善点があります。`DES_ENCRYPT` と `DES_DECRYPT` 関数はバージョン 10.10 以降では廃止されました。詳細については、「[SFORMAT](https://mariadb.com/kb/en/sformat/)」を参照してください。
+ **InnoDB の機能強化** — これらの機能には、次の項目があります。
+ REDO ログのパフォーマンスが向上し、書き込みの増幅が減り、同時実行性が向上しました。
+ データディレクトリを再初期化しなくても、UNDO テーブルスペースを変更できるようになりました。この機能強化により、コントロールプレーンのオーバーヘッドが軽減されます。再起動は必要ですが、undo テーブルスペースを変更した後に再初期化する必要はありません。
+ `CHECK TABLE … EXTENDED` および内部での降順インデックスのサポート。
+ 一括挿入が改善されました。
+ **バイナリログの変更** — これらの変更には、次の項目があります。
+ 2 つのフェーズに `ALTER` のログを記録することにより、レプリケーションのレイテンシーを減少させます。`binlog_alter_two_phase` パラメータはデフォルトでは無効になっていますが、パラメータグループを通じて有効にできます。
+ `explicit_defaults_for_timestamp` のログ記録。
+ トランザクションを安全にロールバックできる場合、`INCIDENT_EVENT` のログ記録は行われなくなりました。
+ **レプリケーション**の**改善** — MariaDB バージョン 10.11 DB インスタンスは、デフォルトで GTID レプリケーションを使用します (マスターがサポートしている場合)。また、`Seconds_Behind_Master` はより正確です。
+ **クライアント** — `mysqlbinglog` および `mariadb-dump` の新しいコマンドラインオプションを使用できます。`mariadb-dump` を使用して、履歴データをダンプして復元できます。
+ **システムバージョン管理** — 履歴を変更できます。MariaDB は自動的に新しいパーティションを作成します。
+ **アトミック DDL** — `CREATE OR REPLACE` がアトミックになりました。ステートメントは連続するか、完全に反転するかのどちらかです。
+ **ログの書き込みをやり直す** — ログの書き込みを非同期でやり直します。
+ **ストアド関数** — ストアド関数が、ストアドプロシージャと同じ`IN`、`OUT`、と `INOUT` パラメータをサポートするようになりました。
+ **非推奨または削除されたパラメータ** — 次のパラメータは、MariaDB バージョン 10.11 DB インスタンスに対して廃止または削除されました。
+ [innodb\$1change\$1buffering](https://mariadb.com/kb/en/innodb-system-variables/#innodb_change_buffering)
+ [innodb\$1disallow\$1writes](https://mariadb.com/kb/en/innodb-system-variables/#innodb_disallow_writes)
+ [innodb\$1log\$1write\$1ahead\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_write_ahead_size)
+ [ innodb\$1prefix\$1index\$1cluster\$1optimization](https://mariadb.com/kb/en/innodb-system-variables/#innodb_prefix_index_cluster_optimization)
+ [ keep\$1files\$1on\$1create](https://mariadb.com/kb/en/server-system-variables/#keep_files_on_create)
+ [old](https://mariadb.com/kb/en/server-system-variables/#old)
+ **ダイナミックパラメータ** — 次のパラメータには、MariaDB バージョン 10.11 DB インスタンスに対して動的になりました。
+ [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size)
+ [innodb\$1write\$1io\$1threads](https://mariadb.com/kb/en/innodb-system-variables/#innodb_write_io_threads)
+ [innodb\$1read\$1io\$1threads](https://mariadb.com/kb/en/innodb-system-variables/#innodb_read_io_threads)
+ **パラメータの新しいデフォルト値** – 次のパラメータには、MariaDB バージョン 10.11 DB インスタンスの新しいデフォルト値があります。
+ [explicit\$1defaults\$1for\$1timestamp](https://mariadb.com/kb/en/server-system-variables/#explicit_defaults_for_timestamp) パラメータのデフォルト値が、`OFF` から `ON` に変更されました。
+ [optimizer\$1prune\$1level](https://mariadb.com/kb/en/server-system-variables/#optimizer_prune_level) パラメータのデフォルト値が、`1` から `2` に変更されました。
+ **パラメータの新しい有効値** – 次のパラメータには、MariaDB バージョン 10.11 DB インスタンスの新しい有効値があります。
+ [old](https://mariadb.com/kb/en/server-system-variables/#old) パラメータの有効値が、[old\$1mode](https://mariadb.com/kb/en/server-system-variables/#old_mode) パラメータの有効値に統合されました。
+ [histogram\$1type](https://mariadb.com/kb/en/server-system-variables/#histogram_type) パラメータの有効値に、`JSON_HB` が含まれるようになりました。
+ [innodb\$1log\$1buffer\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_buffer_size) パラメータの有効値の範囲が、`262144` から `4294967295` (256 キロバイトから 4096 メガバイト) になりました。
+ [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size) パラメータの有効値の範囲が、`4194304` から `512GB` (4 メガバイトから 512 ギガバイト) になりました。
+ [optimizer\$1prune\$1level](https://mariadb.com/kb/en/server-system-variables/#optimizer_prune_level) パラメータの有効値に、`2` が含まれるようになりました。
+ **新しいパラメータ** — 次のパラメータには、MariaDB バージョン 10.11 DB インスタンスに対して新しくなりました。
+ [binlog\$1alter\$1two\$1phase](https://mariadb.com/kb/en/replication-and-binary-log-system-variables//#binlog_alter_two_phase) パラメータは、レプリケーションパフォーマンスを改善できます。
+ [log\$1slow\$1min\$1examined\$1row\$1limit](https://mariadb.com/kb/en/server-system-variables/#log_slow_min_examined_row_limit) は、パフォーマンスを改善できます。
+ [log\$1slow\$1query](https://mariadb.com/kb/en/server-system-variables/#log_slow_query) パラメータと [log\$1slow\$1query\$1file](https://mariadb.com/kb/en/server-system-variables/#log_slow_query_file) パラメータは、`slow_query_log` と `slow_query_log_file` それぞれのエイリアスです。
+ [ optimizer\$1extra\$1pruning\$1depth](https://mariadb.com/kb/en/server-system-variables/#optimizer_extra_pruning_depth)
+ [system\$1versioning\$1insert\$1history](https://mariadb.com/kb/en/system-versioned-tables/#system_versioning_insert_history)
MariaDB 10.11 のすべての機能と関連ドキュメントのリストについては、MariaDB ウェブサイトで「[Changes and improvements in MariaDB 10.11](https://mariadb.com/kb/en/changes-improvements-in-mariadb-1011/)」および「[Release notes - MariaDB 10.11 series](https://mariadb.com/kb/en/release-notes-mariadb-1011-series/)」を参照してください。
サポートされない機能の一覧については、「[Amazon RDS でサポートされていない MariaDB の機能](MariaDB.Concepts.FeatureNonSupport.md)」を参照してください。
### Amazon RDS での MariaDB 10.6 のサポート
Amazon RDS は、MariaDB バージョン 10.6 以降を実行する DB インスタンスで以下の新しい機能をサポートしています。
+ **MyRocks ストレージエンジン** – MyRocks ストレージエンジンを RDS for MariaDB とともに使用して、書き込み負荷の高い高性能ウェブアプリケーションのストレージ消費を最適化できます。詳細については、「[Amazon RDS の MariaDB でサポートされているストレージエンジン](MariaDB.Concepts.Storage.md)」と「[MyRocks](https://mariadb.com/kb/en/myrocks/)」を参照してください。
+ **AWS Identity and Access ManagementIAM DB authentication** (IAM データベース認証) – IAM DB 認証を使用して、MariaDB DB インスタンスへの接続のセキュリティを強化し、一元管理できます。詳細については、「[MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)」を参照してください。
+ **アップグレードオプション** – 以前のメジャーリリース (10.3、10.4、10.5) から RDS for MariaDB バージョン 10.6 にアップグレードできるようになりました。既存の MySQL 5.6 または 5.7 DB インスタンスのスナップショットを MariaDB 10.6 インスタンスに復元することもできます。(詳しくは、「[MariaDB DB エンジンのアップグレード](USER_UpgradeDBInstance.MariaDB.md)」を参照してください。)
+ **レプリケーションの遅延** – リードレプリカがソースデータベースより遅延する時間を設定できるようになりました。標準の MariaDB レプリケーション設定では、ソースとレプリカ間のレプリケーション遅延は最小限に抑えられます。レプリケーションの遅延では、災害対策用の戦略として意図的に遅延を設定できます。詳細については、「[MariaDB での遅延レプリケーションの設定](USER_MariaDB.Replication.ReadReplicas.DelayReplication.md)」を参照してください。
+ **Oracle PL/SQL の互換性** – RDS for MariaDB バージョン 10.6 を使用すると、レガシー Oracle アプリケーションを Amazon RDS にさらに簡単に移行できます。詳細については、「[SQL\$1MODE=ORACLE](https://mariadb.com/kb/en/sql_modeoracle/)」を参照してください。
+ **アトミック DDL** – RDS for MariaDB バージョン 10.6 では、動的データ言語 (DDL) ステートメントは比較的クラッシュセーフです。`CREATE TABLE`、`ALTER TABLE`、`RENAME TABLE`、`DROP TABLE`、`DROP DATABASE`、および関連する DDL ステートメントがアトミックになりました。ステートメントは連続するか、完全に反転するかのどちらかです。詳細については、「[Atomic DDL](https://mariadb.com/kb/en/atomic-ddl/)」(アトミック DDL) を参照してください。
+ **その他の機能強化** – SQL 内で JSON データをリレーショナル形式に変換する `JSON_TABLE` 関数や、Innodb による空のテーブルデータのロードの高速化などの機能強化が行われました。また、分析とトラブルシューティングのための新しい `sys_schema`、未使用のインデックスを無視するためのオプティマイザの機能強化、およびパフォーマンスの向上も行いました。詳細については、「[JSON\$1TABLE](https://mariadb.com/kb/en/json_table/)」を参照してください。
+ **パラメータの新しいデフォルト値** – 次のパラメータには、MariaDB バージョン 10.6 DB インスタンスの新しいデフォルト値があります。
+ 次のパラメータのデフォルト値が `utf8` から `utf8mb3` に変更されました。
+ [character\$1set\$1client](https://mariadb.com/kb/en/server-system-variables/#character_set_client)
+ [character\$1set\$1connection](https://mariadb.com/kb/en/server-system-variables/#character_set_connection)
+ [character\$1set\$1results](https://mariadb.com/kb/en/server-system-variables/#character_set_results)
+ [character\$1set\$1system](https://mariadb.com/kb/en/server-system-variables/#character_set_system)
これらのパラメータのデフォルト値は変更されていますが、機能の変更はありません。詳細については、MariaDB ドキュメントの「[Supported Character Sets and Collations](https://mariadb.com/kb/en/supported-character-sets-and-collations/)」(サポートされている文字セットと照合順序) を参照してください。
+ [collation\$1connection](https://mariadb.com/kb/en/server-system-variables/#collation_connection) パラメータのデフォルト値が `utf8_general_ci` から `utf8mb3_general_ci` に変更されました。このパラメータのデフォルト値は変更されていますが、機能の変更はありません。
+ [old\$1mode](https://mariadb.com/kb/en/server-system-variables/#old_mode) パラメータのデフォルト値が未設定から `UTF8_IS_UTF8MB3` に変更されました。このパラメータのデフォルト値は変更されていますが、機能の変更はありません。
MariaDB 10.6 のすべての機能と関連ドキュメントのリストについては、MariaDB ウェブサイトで「[Changes and improvements in MariaDB 10.6](https://mariadb.com/kb/en/changes-improvements-in-mariadb-106/)」(MariaDB 10.6 の変更点と改善点) および「[Release notes - MariaDB 10.6 series](https://mariadb.com/kb/en/release-notes-mariadb-106-series/)」(リリースノート - MariaDB 10.6 シリーズ) を参照してください。
サポートされない機能の一覧については、「[Amazon RDS でサポートされていない MariaDB の機能](MariaDB.Concepts.FeatureNonSupport.md)」を参照してください。
### Amazon RDS での MariaDB 10.5 のサポート
Amazon RDS は、MariaDB バージョン 10.5 以降を実行する DB インスタンスで以下の新しい機能をサポートしています。
+ **InnoDB の強化 ** - MariaDB バージョン 10.5 には、InnoDB の機能強化が含まれています。詳細については、MariaDB ドキュメントの「[ InnoDB: パフォーマンスの改善など](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/#innodb-performance-improvements-etc)」を参照してください。
+ **Performance Schemaの更新** - MariaDB バージョン 10.5 には、Performance Schemaの更新が含まれています。詳細については、MariaDB ドキュメントの「[MySQL 5.7 インストルメンテーションとテーブルと一致する Performance Schema の更新](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/#performance-schema-updates-to-match-mysql-57-instrumentation-and-tables)」を参照してください。
+ **InnoDB 再実行ログ内の 1 つのファイル ** - MariaDB のバージョン 10.5 より前のバージョンでは、`innodb_log_files_in_group` パラメータの値が `2` に設定されていました。MariaDB バージョン 10.5 では、このパラメータの値は `1` に設定されます。
以前のバージョンから MariaDB バージョン 10.5 にアップグレードし、パラメータを変更しない場合、`innodb_log_file_size` パラメータ値は変更されません。ただし、2 つのログファイルではなく 1 つのログファイルに適用されます。その結果、アップグレードされた MariaDB バージョン 10.5 DB インスタンスは、アップグレード前に使用していた再実行ログサイズの半分を使用します。この変更は、パフォーマンスに顕著な影響を与える可能性があります。この問題に対処するには、`innodb_log_file_size` パラメータの値を 2 倍にします。パラメータの変更については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
+ **SHOW SLAVE STATUS コマンドはサポートされていません**。- MariaDB のバージョン 10.5 より前のバージョンでは、`SHOW SLAVE STATUS`コマンドに `REPLICATION SLAVE` 特権が必要でした。MariaDB バージョン 10.5 では、同等の `SHOW REPLICA STATUS` コマンドに `REPLICATION REPLICA ADMIN` 権限が必要です。この新しい特権は RDS マスターユーザーに付与されません。
`SHOW REPLICA STATUS` コマンドを使用する代わりに、新しい `mysql.rds_replica_status` 保存済み手順を実行して、同様の情報を返します。詳細については、「[mysql.rds\$1replica\$1status](mysql_rds_replica_status.md)」を参照してください。
+ **SHOW RELAYLOG EVENTS コマンドはサポートされていません**。-MariaDB のバージョン 10.5 より前のバージョンでは、`SHOW RELAYLOG EVENTS` コマンドには `REPLICATION SLAVE` 特権が必要でした。MariaDB バージョン 10.5 では、このコマンドには `REPLICATION REPLICA ADMIN` 特権が必要です。この新しい特権は RDS マスターユーザーに付与されません。
+ **パラメータの新しいデフォルト値** - 次のパラメータには、MariaDB バージョン 10.5 DB インスタンスの新しいデフォルト値があります。
+ [max\$1connections](https://mariadb.com/kb/en/server-system-variables/#max_connections) パラメータのデフォルト値が `LEAST({DBInstanceClassMemory/25165760},12000)` に変更されました。`LEAST`パラメータ関数の詳細については、「[DB パラメータ関数](USER_ParamValuesRef.md#USER_ParamFunctions)」を参照してください。
+ [innodb\$1adaptive\$1hash\$1index](https://mariadb.com/kb/en/innodb-system-variables/#innodb_adaptive_hash_index) パラメータのデフォルト値が `OFF` (`0`) に変更されました。
+ [innodb\$1checksum\$1algorythm](https://mariadb.com/kb/en/innodb-system-variables/#innodb_checksum_algorithm)のパラメータのデフォルト値が `full_crc32` に変更されました。
+ [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size) パラメータのデフォルト値が 2 GB に変更されました。
MariaDB 10.5 のすべての機能と関連ドキュメントのリストについては、MariaDB ウェブサイトで「[MariaDB 10.5 の変更点と改善点](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/)」および「[リリースノート - MariaDB 10.5 シリーズ](https://mariadb.com/kb/en/release-notes-mariadb-105-series/)」を参照してください。
サポートされない機能の一覧については、「[Amazon RDS でサポートされていない MariaDB の機能](MariaDB.Concepts.FeatureNonSupport.md)」を参照してください。
### Amazon RDS での MariaDB 10.4 のサポート
Amazon RDS は、MariaDB バージョン 10.4 以降を実行する DB インスタンスで以下の新しい機能をサポートしています。
+ **ユーザーアカウントのセキュリティの強化** - [パスワードの有効期限](https://mariadb.com/kb/en/user-password-expiry/)と[アカウントのロック](https://mariadb.com/kb/en/account-locking/)の改善
+ **オプティマイザの機能強化** - [オプティマイザのトレース機能](https://mariadb.com/kb/en/optimizer-trace-overview/)
+ **InnoDB の機能強化 ** - [インスタント DROP COLUMN のサポート](https://mariadb.com/kb/en/alter-table/#drop-column)と `VARCHAR` および `ROW_FORMAT=DYNAMIC` に対する `ROW_FORMAT=COMPACT` のエクステンション
+ **新しいパラメータ** - [tcp\$1nodedelay](https://mariadb.com/kb/en/server-system-variables/#tcp_nodelay)、[tls\$1version](https://mariadb.com/kb/en/ssltls-system-variables/#tls_version)、および [gtid\$1cleanup\$1batch\$1size](https://mariadb.com/kb/en/gtid/#gtid_cleanup_batch_size) を含む
MariaDB 10.4 のすべての機能と関連ドキュメントのリストについては、MariaDB ウェブサイトで「[MariaDB 10.4 の変更点と改善点](https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-104/)」および「[リリースノート - MariaDB 10.4 シリーズ](https://mariadb.com/kb/en/library/release-notes-mariadb-104-series/)」を参照してください。
サポートされない機能の一覧については、「[Amazon RDS でサポートされていない MariaDB の機能](MariaDB.Concepts.FeatureNonSupport.md)」を参照してください。
# Amazon RDS の MariaDB でサポートされているストレージエンジン
RDS for MariaDB では、次のストレージエンジンがサポートされています。
**Topics**
+ [InnoDB ストレージエンジン](#MariaDB.Concepts.Storage.InnoDB)
+ [MyRocks ストレージエンジン](#MariaDB.Concepts.Storage.MyRocks)
他のストレージエンジンは現在、RDS for MariaDB ではサポートされていません。
## InnoDB ストレージエンジン
MariaDB では様々な機能を持つ複数のストレージエンジンがサポートされていますが、それらすべてがリカバリとデータ耐久性に最適化されているわけではありません。InnoDB は、Amazon RDS での MariaDB DB インスタンスについて推奨されているストレージエンジンです。Amazon RDS でのポイントインタイムの復元やスナップショット復元などの機能には、回復可能なストレージエンジンが必要であり、MariaDB バージョンで推奨された ストレージエンジンのみがサポートされています。
詳細については、「[InnoDB](https://mariadb.com/kb/en/innodb/)」を参照してください。
## MyRocks ストレージエンジン
MyRocks ストレージエンジンは RDS で MariaDB バージョン 10.6 以降で使用可能です。MyRocks ストレージエンジンを本番データベースで使用する前に、徹底したベンチマークとテストを実行して、ユースケースに対する InnoDB の潜在的な利点を検証することをお勧めします。
MariaDB バージョン 10.6 のデフォルトのパラメータグループには MyRocks パラメータが含まれています。詳細については、「[MariaDB のパラメータ](Appendix.MariaDB.Parameters.md)」および「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
MyRocks ストレージエンジンを使用するテーブルを作成するには、`CREATE TABLE` ステートメントに `ENGINE=RocksDB` を指定します。次の例では、MyRocks ストレージエンジンを使用するテーブルを作成します。
```
CREATE TABLE test (a INT NOT NULL, b CHAR(10)) ENGINE=RocksDB;
```
InnoDB テーブルと MyRocks テーブルの両方にまたがるトランザクションを実行しないことを強くお勧めします。MariaDB は、ストレージエンジン間のトランザクションに対して ACID (不可分性、整合性、分離性、耐久性) を保証するものではありません。DB インスタンスに InnoDB テーブルと MyRocks テーブルの両方を含めることは可能ですが、一方のストレージエンジンから別のストレージエンジンへの移行中を除き、この方法はお勧めしません。InnoDB テーブルと MyRocks テーブルの両方が DB インスタンスに存在する場合、各ストレージエンジンには独自のバッファプールがあり、パフォーマンスが低下する可能性があります。
MyRocks では `SERIALIZABLE` アイソレーションまたはギャップロックはサポートされていません。したがって、一般的に MyRocks をステートメントベースのレプリケーションで使用することはできません。詳細については、「[MyRocks and Replication](https://mariadb.com/kb/en/myrocks-and-replication/)」(MyRocks とレプリケーション) を参照してください。
現在、次の MyRocks パラメータのみ変更できます。
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_block_cache_size](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_block_cache_size)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load_size](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load_size)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect_depth](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect_depth)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_max_latest_deadlocks](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_max_latest_deadlocks)
MyRocks ストレージエンジンと InnoDB ストレージエンジンは、`rocksdb_block_cache_size` および `innodb_buffer_pool_size` パラメータの設定により競合する可能性があります。場合によっては、特定の DB インスタンスで MyRocks ストレージエンジンのみを使用したいことがあります。その場合は、`innodb_buffer_pool_size minimal` パラメータを最小値に設定し、`rocksdb_block_cache_size` をできる限り高く設定することをお勧めします。
[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) および [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html) オペレーションを使用して MyRocks ログファイルにアクセスできます。
MyRocks の詳細については、MariaDB のウェブサイトの「[MyRocks](https://mariadb.com/kb/en/myrocks/)」を参照してください。
# Amazon RDS での MariaDB のキャッシュウォームアップ
InnoDB キャッシュウォームアップでは、DB インスタンスがシャットダウンされたときのバッファプールの最新の状態を保存し、DB インスタンスが起動されたときに保存された情報からバッファプールを再ロードすることによって、MariaDB DB インスタンスのパフォーマンスを向上させることができます。このアプローチにより、通常のデータベースの使用からバッファプールを「ウォームアップする」必要がなくなり、既知の一般的なクエリのページを使用してバッファプールを事前にロードします。キャッシュウォームアップの詳細については、MariaDB ドキュメントの「[バッファプールのダンプと復元](http://mariadb.com/kb/en/mariadb/xtradbinnodb-buffer-pool/#dumping-and-restoring-the-buffer-pool)」を参照してください。
MariaDB 10.3 以上の DB インスタンスでは、キャッシュウォームアップはデフォルトで有効になっています。有効にするには、DB インスタンスのパラメータグループで `innodb_buffer_pool_dump_at_shutdown` および `innodb_buffer_pool_load_at_startup` パラメータを 1 に設定します。パラメータグループのこれらのパラメータ値を変更すると、パラメータグループを使用するすべての MariaDB DB インスタンスに影響します。特定の MariaDB DB インスタンスの キャッシュウォームアップを有効にするには、それらの DB インスタンスの新しいパラメータグループを作成することが必要になる場合があります。パラメータグループについては、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
キャッシュウォームアップは、主に、スタンダードストレージを使用する DB インスタンスにパフォーマンス上のメリットをもたらします。PIOPS ストレージを使用する場合、一般的に大きなパフォーマンス上のメリットは見られません。
**重要**
フェイルオーバー時など、MariaDB DB インスタンスが正常にシャットダウンしなかった場合、バッファプールの状態はディスクに保存されません。この場合、DB インスタンスが再開されるときに、MariaDB は利用可能なバッファプールファイルをロードします。特に害はありませんが、復元済みバッファプールは、再起動前のバッファプールの最新の状態を反映していない可能性があります。スタートアップ時に キャッシュをウォームアップするために、バッファプールの最新の状態を利用できるように、定期的に「オンデマンド」でバッファプールをダンプすることをお勧めします。バッファプールをオンデマンドでダンプまたはロードできます。
自動で定期的にバッファプールをダンプするイベントを作成できます。例えば、次のステートメントは、1 時間ごとにバッファプールをダンプする `periodic_buffer_pool_dump` という名前のイベントを作成します。
```
1. CREATE EVENT periodic_buffer_pool_dump
2. ON SCHEDULE EVERY 1 HOUR
3. DO CALL mysql.rds_innodb_buffer_pool_dump_now();
```
詳細については、MariaDB のドキュメントの「[イベント](http://mariadb.com/kb/en/mariadb/stored-programs-and-views-events/)」を参照してください。
## オンデマンドでのバッファプールのダンプとロード
次のストアドプロシージャを使用して、 キャッシュをオンデマンドで格納しロードできます。
+ バッファプールの現在の状態をディスクにダンプするには、[mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_dump_now) ストアドプロシージャを呼び出します。
+ バッファプールの保存された状態をディスクからロードするには、[mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_now) ストアドプロシージャを呼び出します。
+ 進行中のロードオペレーションをキャンセルするには、[mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_abort) ストアドプロシージャを呼び出します。
# Amazon RDS でサポートされていない MariaDB の機能
以下の MariaDB 機能は、Amazon RDS ではサポートされていません。
+ S3 ストレージエンジン
+ 認証用プラグイン - GSSAPI
+ 認証用プラグイン - Unix ソケット
+ AWS Key Management 暗号化プラグイン
+ 10.6 より前のバージョンの MariaDB の遅延レプリケーション
+ InnoDB および Aria で保管時のネイティブ MariaDB 暗号化
MariaDB DB インスタンス用に保管時の暗号化を有効にするには、「[Amazon RDS リソースの暗号化](Overview.Encryption.md)」の指示に従います。
+ HandlerSocket
+ 10.6 より前のバージョンの MariaDB の JSON テーブルタイプ
+ MariaDB ColumnStore
+ MariaDB Galera クラスター
+ マルチ出典レプリケーション
+ 10.6 より前のバージョンの MariaDB の MyRocks ストレージエンジン
+ 11.4 より前のバージョンの MariaDB のパスワード検証プラグイン `simple_password_check` および `cracklib_password_check`
+ Spider ストレージエンジン
+ Sphinx ストレージエンジン
+ TokuDB ストレージエンジン
+ MariaDB ドキュメントの「[エンジン定義の新しいテーブル/フィールド/インデックス属性](http://mariadb.com/kb/en/mariadb/engine-defined-new-tablefieldindex-attributes/)」で説明されている、ストレージエンジン固有のオブジェクト属性。
+ テーブルとテーブルスペースの暗号化
+ Hashicorp Key Management プラグイン
+ 2 つのアップグレードを平行実行
マネージド型サービスの操作性を実現するために、Amazon RDS では DB インスタンスへのシェルアクセスはできません。また、上位の権限を必要とする特定のシステムプロシージャやシステムテーブルへのアクセスが制限されます。Amazon RDS は、任意のスタンダード SQL クライアントアプリケーションによる、DB インスタンス上のデータベースへのアクセスがサポートされています。Amazon RDS では、Telnet、Secure Shell (SSH)、または Windows のリモートデスクトップ接続を使用しての、DB インスタンスに対するダイレクトホストアクセスは行えません。
# Amazon RDS の MariaDB のバージョン
MariaDB の場合、バージョン番号は「バージョン X.Y.Z 」の形式で記述されます。Amazon RDS の用法では、X.Y はメジャーバージョン番号を、Z はマイナーバージョン番号を表します。Amazon RDS 実装では、メジャーバージョン番号が変更された場合 (10.5 から 10.6 へなど)、そのバージョン変更はメジャーと考えます。マイナーバージョン番号のみが変更された場合 (10.6.14 から 10.6.16 へなど)、そのバージョン変更はマイナーと考えます。
**Topics**
+ [Amazon RDS でサポートされている MariaDB のマイナーバージョン](#MariaDB.Concepts.VersionMgmt.Supported)
+ [Amazon RDS でサポートされている MariaDB のメジャーバージョン](#MariaDB.Concepts.VersionMgmt.ReleaseCalendar)
+ [データベースプレビュー環境の使用](#mariadb-working-with-the-database-preview-environment)
+ [データベースプレビュー環境の MariaDB バージョン 11.7](#mariadb-preview-environment-version-11-7)
+ [Amazon RDS for MariaDB の非推奨バージョン](#MariaDB.Concepts.DeprecatedVersions)
## Amazon RDS でサポートされている MariaDB のマイナーバージョン
Amazon RDS は、現在、MariaDB の以下のマイナーバージョンをサポートしています。
**注記**
月と年のみの日付はおおよその日付であり、確定後に正確な日付で更新されます。
次の表に、Amazon RDS が現在サポートしている MariaDB 11.8 のマイナーバージョンを示します。
| MariaDB エンジンバージョン | コミュニティリリース日 | RDS リリース日 | RDS 標準サポート終了日 |
| --- | --- | --- | --- |
| 11.8.6 | 2026 年 2 月 4 日 | 2026 年 2 月 10 日 | 2027 年 2 月 |
| 11.8.5 | 2025 年 11 月 14 日 | 2025 年 11 月 20 日 | 2026 年 11 月 |
| 11.8.3 | 2025 年 8 月 6 日 | 2025 年 8 月 25 日 | 2026 年 9 月 |
次の表に、Amazon RDS が現在サポートしている MariaDB 11.4 のマイナーバージョンを示します。
| MariaDB エンジンバージョン | コミュニティリリース日 | RDS リリース日 | RDS 標準サポート終了日 |
| --- | --- | --- | --- |
| 11.4.10 | 2026 年 2 月 4 日 | 2026 年 2 月 10 日 | 2027 年 2 月 |
| 11.4.9 | 2025 年 11 月 6 日 | 2025 年 11 月 18 日 | 2026 年 11 月 |
| 11.4.8 | 2025 年 8 月 6 日 | 2025 年 8 月 13 日 | 2026 年 9 月 |
| 11.4.7 | 2025 年 5 月 22 日 | 2025 年 6 月 4 日 | 2026 年 9 月 |
| 11.4.5 | 2025 年 2 月 4 日 | 2025 年 2 月 24 日 | 2026 年 5 月 |
| 11.4.4 | 2024 年 11 月 1 日 | 2024 年 12 月 20 日 | 2026 年 5 月 |
| 11.4.3 | 2024 年 8 月 8 日 | 2024 年 10 月 15 日 | 2026 年 5 月 |
次の表に、Amazon RDS が現在サポートしている MariaDB 10.11 のマイナーバージョンを示します。
| MariaDB エンジンバージョン | コミュニティリリース日 | RDS リリース日 | RDS 標準サポート終了日 |
| --- | --- | --- | --- |
| 10.11.16 | 2026 年 2 月 4 日 | 2026 年 2 月 10 日 | 2027 年 2 月 |
| 10.11.15 | 2025 年 11 月 6 日 | 2025 年 11 月 18 日 | 2026 年 11 月 |
| 10.11.14 | 2025 年 8 月 6 日 | 2025 年 8 月 13 日 | 2026 年 9 月 |
| 10.11.13 | 2025 年 5 月 22 日 | 2025 年 6 月 4 日 | 2026 年 9 月 |
| 10.11.11 | 2025 年 2 月 4 日 | 2025 年 2 月 24 日 | 2026 年 5 月 |
| 10.11.10 | 2024 年 11 月 1 日 | 2024 年 12 月 20 日 | 2026 年 5 月 |
| 10.11.9 | 2024 年 8 月 8 日 | 2024 年 9 月 4 日 | 2026 年 5 月 |
次の表に、Amazon RDS が現在サポートしている MariaDB 10.6 のマイナーバージョンを示します。
| MariaDB エンジンバージョン | コミュニティリリース日 | RDS リリース日 | RDS 標準サポート終了日 |
| --- | --- | --- | --- |
| 10.6.25 | 2026 年 2 月 4 日 | 2026 年 2 月 10 日 | 2026 年 7 月 |
| 10.6.24 | 2025 年 11 月 6 日 | 2025 年 11 月 18 日 | 2026 年 7 月 |
| 10.6.23 | 2025 年 8 月 6 日 | 2025 年 8 月 13 日 | 2026 年 7 月 |
| 10.6.22 | 2025 年 5 月 6 日 | 2025 年 5 月 20 日 | 2026 年 7 月 |
| 10.6.21 | 2025 年 2 月 4 日 | 2025 年 2 月 24 日 | 2026 年 5 月 |
| 10.6.20 | 2024 年 11 月 1 日 | 2024 年 12 月 20 日 | 2026 年 5 月 |
| 10.6.19 | 2024 年 8 月 8 日 | 2024 年 9 月 4 日 | 2026 年 5 月 |
次の表に、Amazon RDS が現在サポートしている MariaDB 10.5 のマイナーバージョンを示します。
| MariaDB エンジンバージョン | コミュニティリリース日 | RDS リリース日 | RDS 標準サポート終了日 |
| --- | --- | --- | --- |
| 10.5.29 | 2025 年 5 月 6 日 | 2025 年 5 月 20 日 | 2026 年 6 月 |
| 10.5.28 | 2025 年 2 月 4 日 | 2025 年 2 月 24 日 | 2026 年 6 月 |
| 10.5.27 | 2024 年 11 月 1 日 | 2024 年 12 月 20 日 | 2026 年 5 月 |
新しい DB インスタンスを作成するときは、現在サポートされているいずれかの MariaDB バージョンを指定できます。メジャーバージョン (MariaDB 10.5 など) と、指定したメジャーバージョンでサポートされている任意のマイナーバージョンを指定できます。バージョンを指定しない場合、Amazon RDS では、サポートされているいずれかのバージョン (通常最新のバージョン) がデフォルトで設定されます。マイナーバージョンではなく、メジャーバージョンを指定した場合は、Amazon RDS では、お客様が指定したメジャーバージョンの最新リリースにデフォルトで設定されます。サポートされているバージョンのリストと、新しく作成された DB インスタンスのデフォルトを表示するには、AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを使用します。
例えば、RDS for MariaDB でサポートされているエンジンバージョンを一覧表示するには、次の CLI コマンドを実行します。
```
aws rds describe-db-engine-versions --engine mariadb --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
デフォルトの MariaDB バージョンは、AWS リージョン によって異なる場合があります。特定のマイナーバージョンで DB インスタンスを作成するには、DB インスタンスの作成中にマイナーバージョンを指定します。次の AWS リージョン コマンドを実行して、AWS CLI のデフォルトのマイナーバージョンを確認できます。
```
aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version major_engine_version --region region --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
*major-engine-version* をメジャーエンジンバージョンに置き換え、*リージョン*を AWS リージョン に置き換えます。例えば、次の AWS CLI コマンドは、10.5 メジャーバージョンおよび米国西部 (オレゴン) AWS リージョン (us-west-2) 用の、デフォルトの MariaDB マイナーエンジンのバージョンを返します。
```
aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version 10.5 --region us-west-2 --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
### Amazon RDS の MariaDB マイナーバージョン
**Topics**
+ [MariaDB バージョン 11.8.6](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.6)
+ [MariaDB バージョン 11.8.5](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.5)
+ [MariaDB バージョン 11.8.3](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.3)
+ [MariaDB バージョン 11.4.10](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.10)
+ [MariaDB バージョン 11.4.9](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.9)
+ [MariaDB バージョン 11.4.8](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.8)
+ [MariaDB バージョン 11.4.7](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.7)
+ [MariaDB バージョン 11.4.5](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.5)
+ [MariaDB バージョン 11.4.4](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.4)
+ [MariaDB バージョン 10.11.16](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.16)
+ [MariaDB バージョン 10.11.15](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.15)
+ [MariaDB バージョン 10.11.14](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.14)
+ [MariaDB バージョン 10.11.13](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.13)
+ [MariaDB バージョン 10.11.11](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.11)
+ [MariaDB バージョン 10.11.10](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.10)
+ [MariaDB バージョン 10.6.25](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.25)
+ [MariaDB バージョン 10.6.24](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.24)
+ [MariaDB バージョン 10.6.23](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.23)
+ [MariaDB バージョン 10.6.22](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.22)
+ [MariaDB バージョン 10.6.21](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.21)
+ [MariaDB バージョン 10.6.20](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.20)
+ [MariaDB バージョン 10.5.29](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.29)
+ [MariaDB バージョン 10.5.28](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.28)
+ [MariaDB バージョン 10.5.27](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.27)
#### MariaDB バージョン 11.8.6
Amazon RDS で MariaDB バージョン 11.8.6 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025c` に基づいてタイムゾーン情報を更新しました。
+ 一部の SQL ステートメントが監査ログに記録されない問題を修正しました。
#### MariaDB バージョン 11.8.5
Amazon RDS で MariaDB バージョン 11.8.5 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
#### MariaDB バージョン 11.8.3
Amazon RDS で MariaDB バージョン 11.8.3 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ **パラメータの新しいデフォルト値** – `require_secure_transport` パラメータのデフォルト値が `0` から `1` に変更され、デフォルトで安全なトランスポート接続が強制されます。詳細については、「[Amazon RDS 上の MariaDB DB インスタンスへのすべての接続に SSL/TLS を要求する](mariadb-ssl-connections.require-ssl.md)」を参照してください。
#### MariaDB バージョン 11.4.10
Amazon RDS で MariaDB バージョン 11.4.10 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025c` に基づいてタイムゾーン情報を更新しました。
+ 一部の SQL ステートメントが監査ログに記録されない問題を修正しました。
#### MariaDB バージョン 11.4.9
Amazon RDS で MariaDB バージョン 11.4.9 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
#### MariaDB バージョン 11.4.8
Amazon RDS で MariaDB バージョン 11.4.8 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
#### MariaDB バージョン 11.4.7
Amazon RDS で MariaDB バージョン 11.4.7 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025b` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 11.4.5
Amazon RDS で MariaDB バージョン 11.4.5 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025a` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 11.4.4
Amazon RDS で MariaDB バージョン 11.4.4 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ ポイントインタイムリカバリ (PITR) が失敗する原因となる 2 つの MariaDB コミュニティの変更を元に戻しました。詳細については、「[MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528)」を参照してください。
#### MariaDB バージョン 10.11.16
Amazon RDS で MariaDB バージョン 10.11.16 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025c` に基づいてタイムゾーン情報を更新しました。
+ 一部の SQL ステートメントが監査ログに記録されない問題を修正しました。
#### MariaDB バージョン 10.11.15
Amazon RDS で MariaDB バージョン 10.11.15 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
#### MariaDB バージョン 10.11.14
Amazon RDS で MariaDB バージョン 10.11.14 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
#### MariaDB バージョン 10.11.13
Amazon RDS で MariaDB バージョン 10.11.13 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025b` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 10.11.11
Amazon RDS で MariaDB バージョン 10.11.11 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025a` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 10.11.10
Amazon RDS で MariaDB バージョン 10.11.10 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ ポイントインタイムリカバリ (PITR) が失敗する原因となる 2 つの MariaDB コミュニティの変更を元に戻しました。詳細については、「[MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528)」を参照してください。
#### MariaDB バージョン 10.6.25
Amazon RDS で MariaDB バージョン 10.6.25 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025c` に基づいてタイムゾーン情報を更新しました。
+ 一部の SQL ステートメントが監査ログに記録されない問題を修正しました。
#### MariaDB バージョン 10.6.24
Amazon RDS で MariaDB バージョン 10.6.24 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
#### MariaDB バージョン 10.6.23
Amazon RDS で MariaDB バージョン 10.6.23 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
#### MariaDB バージョン 10.6.22
Amazon RDS で MariaDB バージョン 10.6.22 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025b` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 10.6.21
Amazon RDS で MariaDB バージョン 10.6.21 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025a` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 10.6.20
Amazon RDS で MariaDB バージョン 10.6.20 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ ポイントインタイムリカバリ (PITR) が失敗する原因となる 2 つの MariaDB コミュニティの変更を元に戻しました。詳細については、「[MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528)」を参照してください。
#### MariaDB バージョン 10.5.29
Amazon RDS で MariaDB バージョン 10.5.29 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025b` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 10.5.28
Amazon RDS で MariaDB バージョン 10.5.28 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ `tzdata2025a` に基づいてタイムゾーン情報を更新しました。
#### MariaDB バージョン 10.5.27
Amazon RDS で MariaDB バージョン 10.5.27 が使用可能になりました。このリリースには、MariaDB コミュニティと Amazon RDS によって追加された修正と改善が含まれています。
**新しい特徴と拡張機能**
+ ポイントインタイムリカバリ (PITR) が失敗する原因となる 2 つの MariaDB コミュニティの変更を元に戻しました。詳細については、「[MariaDB Server Jira issue MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528)」を参照してください。
## Amazon RDS でサポートされている MariaDB のメジャーバージョン
RDS for MariaDB メジャーバージョンは、少なくとも対応するコミュニティバージョンのコミュニティが終了するまでの期間利用可能です。次の日付を参考にすると、テストおよびアップグレードのサイクルを計画することができます。Amazon は、RDS for MariaDB バージョンのサポートを当初発表よりも長く延長した場合、新しい日付を反映してこの表を更新するようにします。
**注記**
月と年のみの日付はおおよその日付であり、確定後に正確な日付で更新されます。
[describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) AWS CLI コマンドを実行するか、[DescribeDBMajorEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS API オペレーションを使用して、メジャーエンジンバージョンのサポート日に関する情報を表示することもできます。
| MariaDB メジャーバージョン | コミュニティリリース日 | RDS リリース日 | コミュニティサポート終了日 | RDS 標準サポート終了日 |
| --- | --- | --- | --- | --- |
| MariaDB 11.8 | 2025 年 8 月 6 日 | 2025 年 8 月 25 日 | June 2030 | June 2030 |
| MariaDB 11.4 | 2024 年 8 月 8 日 | 2024年 10 月 15 日 | 2029 年 5 月 | 2029 年 5 月 |
| MariaDB 10.11 | 2023 年 2 月 16 日 | 2023 年 8 月 21 日 | 2028 年 2 月 16 日 | 2028 年 2 月 |
| MariaDB 10.6 | 2021 年 7 月 6 日 | 2022 年 2 月 3 日 | 2026 年 7 月 6 日 | 2026 年 8 月 |
| MariaDB 10.5 | 2020 年 6 月 24 日 | 2021 年 1 月 21 日 | 2025 年 6 月 24 日 | 2026 年 8 月 |
## データベースプレビュー環境の使用
データベースプレビュー環境での RDS for MariaDB DB インスタンスは、他の RDS for MariaDB DB インスタンスと機能的に同様です。ただし、データベースプレビュー環境は本稼働に使用できません。
プレビュー環境には以下の制限があります。
+ Amazon RDS は、すべての DB インスタンスを作成から 60 日後にバックアップおよびスナップショットとともに削除します。
+ 汎用 SSD およびプロビジョンド IOPS SSD ストレージのみを使用できます。
+ DB インスタンスに関して サポート からヘルプを受けることはできません。代わりに、AWS マネージド Q&A コミュニティ、[AWS re:Post](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service) に質問を投稿できます。
+ DB インスタンスのスナップショットを本稼働環境にコピーすることはできません。
プレビューでは、以下のオプションがサポートされています。
+ db.m6i、db.m5、db.m5、db.m5、db.m5、db.m5、db.m5、db.m5、db.m5、db.m5 DB インスタンスクラスを使って DB インスタンスを作成できます。RDS インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
+ シングル AZ 配置とマルチ AZ 配置の両方を使用できます。
+ 標準の MariaDB ダンプおよびロード機能を使用して、データベースをデータベースプレビュー環境からエクスポートしたり、データベースプレビュー環境にインポートしたりできます。
### データベースプレビュー環境でサポートされない機能
以下の機能は、データベースプレビュー環境で使用できません。
+ クロスリージョンスナップショットのコピー
+ クロスリージョンリードレプリカ
+ RDS Proxy
### データベースプレビュー環境での新しい DB インスタンスの作成
AWS マネジメントコンソール、AWS CLI または RDS API を使用して、データベースプレビュー環境で DB インスタンスを作成できます。
#### コンソール
**データベースプレビュー環境で新しい DB インスタンスを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**ダッシュボード**] を選択します。
1. **[ダッシュボード]** ページで、次の図に示すように、**[データベースプレビュー環境]** セクションを見つけます。
![\[Amazon RDS コンソールのリンク付き [データベースプレビュー環境] セクション。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
また、[[データベースプレビュー環境]](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#) に直接移動することもできます。先に進む前に、制限事項を確認して同意する必要があります。
![\[制限を確認するための [データベースプレビュー環境サービス契約] ダイアログ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. RDS for MariaDB DB インスタンスを作成するには、任意の Amazon RDS DB インスタンスを作成する場合と同じプロセスに従います。詳細については、「[DB インスタンスの作成](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating)」の [コンソール](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) 手順を参照してください。
#### AWS CLI
AWS CLI を使用してデータベースプレビュー環境でインスタンスを作成するには、次のエンドポイントを使用します。
```
rds-preview.us-east-2.amazonaws.com
```
RDS for MariaDB DB インスタンスを作成するには、任意の Amazon RDS DB インスタンスを作成する場合と同じプロセスに従います。詳細については、「[DB インスタンスの作成](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating)」の [AWS CLI](USER_CreateDBInstance.md#USER_CreateDBInstance.CLI) 手順を参照してください。
#### RDS API
RDS API を使用してデータベースプレビュー環境でインスタンスを作成するには、次のエンドポイントを使用します。
```
rds-preview.us-east-2.amazonaws.com
```
RDS for MariaDB DB インスタンスを作成するには、任意の Amazon RDS DB インスタンスを作成する場合と同じプロセスに従います。詳細については、「[DB インスタンスの作成](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating)」の [RDS API](USER_CreateDBInstance.md#USER_CreateDBInstance.API) 手順を参照してください。
## データベースプレビュー環境の MariaDB バージョン 11.7
MariaDB バージョン 11.7 が Amazon RDS データベースプレビュー環境で利用可能になりました。MariaDB バージョン 11.7 には、「[Changes and Improvements in MariaDB 11.7](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-7/)」に記載されているいくつかの改善点が含まれています。このバージョンには、ベクトルデータ型、インデックス作成、検索のサポートも含まれています。詳細については、MariaDB ドキュメントの「[Vector Overview](https://mariadb.com/kb/en/vector-overview/)」を参照してください。
データベースプレビュー環境を使用して、本番稼働ワークロードのすべての AWS リージョン で利用できる前に、このリリースに対してワークロードをテストできます。データベースプレビュー環境の詳細については、「[データベースプレビュー環境の使用](#mariadb-working-with-the-database-preview-environment)」を参照してください。コンソールからプレビュー環境にアクセスするには、[rds-preview/](https://console.aws.amazon.com/rds-preview/) を選択します。
## Amazon RDS for MariaDB の非推奨バージョン
Amazon RDS for MariaDB バージョン 10.0、10.1、10.2、10.3 は非推奨です。
MariaDB の Amazon RDS 廃止ポリシーについては、「[Amazon RDS についてのよくある質問](https://aws.amazon.com/rds/faqs/)」を参照してください。
# MariaDB DB インスタンスへの接続
Amazon RDS によって DB インスタンスがプロビジョニングされたら、スタンダードの MariaDB クライアントアプリケーションまたはユーティリティを使用してインスタンスに接続できます。接続文字列で、DB インスタンスのエンドポイントからのドメインネームシステム (DNS) アドレスをホストパラメータとして指定します。また、ポートパラメータとして、DB インスタンスのエンドポイントのポート番号も指定します。
MySQL コマンドラインクライアントなどのツールを使用して、DB インスタンスの Amazon RDS for MariaDB に接続できます。MySQL コマンドラインクライアントの使用についての詳細は、MariaDB ドキュメントの「[mysql コマンドラインクライアント](http://mariadb.com/kb/en/mariadb/mysql-command-line-client/)」を参照してください。接続に使用できる GUI ベースのアプリケーションの 1 つは Heidi です。詳細については、「[HeidiSQL のダウンロード](http://www.heidisql.com/download.php)」ページを参照してください。MySQL のインストール (MySQL コマンドラインクライアントを含む) については、「[MySQL のインストールと更新](https://dev.mysql.com/doc/refman/8.0/en/installing.html)」を参照してください。
ほとんどの Linux ディストリビューションには、Oracle MySQL クライアントではなく MariaDB クライアントが含まれています。MariaDB の MySQL コマンドラインクライアントを Amazon Linux 2023 にインストールするには、次のコマンドを実行します。
```
sudo dnf install mariadb105
```
MariaDB の MySQL コマンドラインクライアントを Amazon Linux 2 にインストールするには、次のコマンドを実行します。
```
sudo yum install mariadb
```
ほとんどの DEB ベースの Linux ディストリビューションに MySQL コマンドラインクライアントをインストールするには、次のコマンドを実行します。
```
apt-get install mariadb-client
```
MySQL コマンドラインクライアントのバージョンを確認するには、次のコマンドを実行します。
```
mysql --version
```
現在のクライアントバージョン用の MySQL ドキュメントを表示するには、次のコマンドを実行します。
```
man mysql
```
Virtual Private Cloud (VPC) の外部から Amazon VPC に基づいて DB インスタンスに接続するには、DB インスタンスがパブリックにアクセスできる必要があります。また、DB インスタンスのセキュリティグループのインバウンドルールを使用してアクセスを許可し、その他の要件を満たしている必要があります。詳細については、「[Amazon RDS DB インスタンスに接続できない](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)」を参照してください。
MariaDB DB インスタンスへの接続には、SSL 暗号化を使用できます。詳細については、[Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS サポート](MariaDB.Concepts.SSLSupport.md) を参照してください。
RDS for MariaDB DB インスタンスを検索して接続するには、次のトピックを参照してください。
**Topics**
+ [MariaDB DB インスタンスの接続情報の検索](USER_ConnectToMariaDBInstance.EndpointAndPort.md)
+ [RDS for MariaDB の MySQL コマンドラインクライアントからの接続 (非暗号化)](USER_ConnectToMariaDBInstance.CLI.md)
+ [AWS JDBC ドライバーと AWS Python ドライバーを使用した RDS for MariaDB への接続](MariaDB.Connecting.Drivers.md)
+ [MariaDB DB インスタンスへの接続のトラブルシューティング](USER_ConnectToMariaDBInstance.Troubleshooting.md)
# MariaDB DB インスタンスの接続情報の検索
DB インスタンスの接続情報には、エンドポイント、ポート、およびマスターユーザーなどの有効なデータベースユーザーが含まれます。例えば、エンドポイントの値が `mydb.123456789012.us-east-1.rds.amazonaws.com` であるとします。この場合、ポート値は `3306` であり、データベースユーザーは `admin` です。この情報を考慮して、接続文字列に次の値を指定します。
+ ホスト、ホスト名または DNS 名には、`mydb.123456789012.us-east-1.rds.amazonaws.com` を指定します。
+ ポートで、`3306` を指定します。
+ ユーザーには、`admin` を指定します。
DB インスタンスに接続するには、MariaDB DB エンジンの任意のクライアントを使用します。例えば、MySQL コマンドラインクライアントまたは MySQL ワークベンチを使用できます。
DB インスタンスの接続情報を検索するには、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI) [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) コマンド、または Amazon RDS API [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) オペレーションを使用して、詳細を一覧表示できます。
## コンソール
**AWS マネジメントコンソール で DB インスタンスの接続情報を探すには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択して DB インスタンスのリストを表示します。
1. MariaDB DB インスタンスの名前を選択して、その詳細を表示します。
1. [**接続とセキュリティ**] タブで、エンドポイントをコピーします。また、ポート番号を書き留めます。DB インスタンスに接続するには、エンドポイントとポート番号の両方が必要です。
![\[Amazon RDS コンソールの DB インスタンスのエンドポイントとポート。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/endpoint-port.png)
1. マスターユーザーネームを見つける必要がある場合は、[**設定**] タブを選択し、[**マスターユーザーネーム**] の値を表示します。
## AWS CLI
AWS CLI を使用して MariaDB DB インスタンスの接続情報を検索するには、[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) コマンドを実行します。呼び出しで、DB インスタンス ID、エンドポイント、ポート、マスターユーザー名をクエリします。
Linux、macOS、Unix の場合:
```
aws rds describe-db-instances \
--filters "Name=engine,Values=mariadb" \
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
Windows の場合:
```
aws rds describe-db-instances ^
--filters "Name=engine,Values=mariadb" ^
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
出力は次のようになります。
```
[
[
"mydb1",
"mydb1.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
],
[
"mydb2",
"mydb2.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
]
]
```
## RDS API
Amazon RDS API を使用して DB インスタンスの接続情報を検索するには、[DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) オペレーションを呼び出します。出力で、エンドポイントアドレス、エンドポイントポート、およびマスターユーザー名の値を検索します。
# RDS for MariaDB の MySQL コマンドラインクライアントからの接続 (非暗号化)
**重要**
クライアントとサーバーが同じ VPC にあり、ネットワークが信頼されている場合に限り、暗号化されていない MySQL 接続を使用します。暗号化された接続の使用については、「[MySQL コマンドラインクライアントからの SSL/TLS による Amazon RDS 上の MariaDB DB インスタンスへの接続 (暗号化）](USER_ConnectToMariaDBInstanceSSL.CLI.md)」を参照してください。
MySQL コマンドラインクライアントを使用して DB インスタンスに接続するには、クライアントコンピュータのコマンドプロンプトで次のコマンドを入力します。これにより、MariaDB DB インスタンスのデータベースに接続されます。*``* の DB インスタンスの DNS 名 (エンドポイント) を、*``* で使用したマスターユーザー名に置き換えます。パスワードの入力を求められたときに使用したマスターパスワードを入力します。
```
mysql -h -P 3306 -u -p
```
ユーザーのパスワードを入力すると、次のような出力が表示されます。
```
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 10.6.10-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
```
# AWS JDBC ドライバーと AWS Python ドライバーを使用した RDS for MariaDB への接続
AWS JDBC ドライバーと AWS Python ドライバーを使用して RDS for MariaDB DB インスタンスに接続します。詳細については、以下のトピックを参照してください。
**Topics**
+ [Amazon Web Services (AWS) JDBC ドライバーを使用した RDS for MariaDB への接続](#MariaDB.Connecting.JDBCDriver)
+ [Amazon Web Services (AWS) Python ドライバーを使用した RDS for MariaDB への接続](#MariaDB.Connecting.PythonDriver)
## Amazon Web Services (AWS) JDBC ドライバーを使用した RDS for MariaDB への接続
Amazon Web Services (AWS) JDBC ドライバーは、高度な JDBC ラッパーとして設計されています。このラッパーは、既存の JDBC ドライバーの機能を補完し、拡張します。ドライバーには、コミュニティ MySQL Connector/J ドライバーおよびコミュニティ MariaDB Connector/J ドライバーとドロップイン互換性があります。
AWS JDBC ドライバーをインストールするには、AWS JDBC ドライバーの .jar ファイル (`CLASSPATH` アプリケーション内) を追加して、それぞれのコミュニティドライバーへの参照を保持します。対応する接続 URL プレフィックスを次のように更新します。
+ `jdbc:mysql://`～`jdbc:aws-wrapper:mysql://`
+ `jdbc:mariadb://`～`jdbc:aws-wrapper:mariadb://`
AWS JDBC ドライバーおよびその使用方法の詳細については、「[Amazon Web Services (AWS) JDBC ドライバー GitHub リポジトリ](https://github.com/awslabs/aws-advanced-jdbc-wrapper)」を参照してください。
## Amazon Web Services (AWS) Python ドライバーを使用した RDS for MariaDB への接続
Amazon Web Services (AWS) Python ドライバーは、高度な Python ラッパーとして設計されています。このラッパーは、オープンソースの Psycopg ドライバーの機能を補完し、拡張します。AWS Python ドライバーは Python バージョン 3.8 以降をサポートしています。`aws-advanced-python-wrapper` パッケージは、`pip` コマンドと `psycopg` オープンソースパッケージを使用してインストールできます。
AWS Python ドライバーおよびその使用方法の詳細については、「[Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/awslabs/aws-advanced-python-wrapper)」を参照してください。
# MariaDB DB インスタンスへの接続のトラブルシューティング
新しい DB インスタンスへの接続に失敗する一般的な原因には、次の 2 つがあります。
+ MariaDB アプリケーションまたはユーティリティが実行されているデバイスまたは Amazon EC2 インスタンスからの接続を許可しないセキュリティグループを使用して DB インスタンスが作成されました。DB インスタンスには、接続を許可する VPC セキュリティグループが必要です。詳しくは、「[Amazon VPC と Amazon RDS](USER_VPC.md)」を参照してください。
セキュリティグループでインバウンドのルールを追加または編集できます。**[ソース]** には **[マイ IP]** を選択します。これにより、ブラウザで検出された IP アドレスから DB インスタンスへのアクセスが許可されます。
+ DB インスタンスが、デフォルトポートの 3306 を使用して作成されたが、会社のファイアウォールルールで、社内ネットワークのデバイスからそのポートへの接続がブロックされています。この問題を解決するには、別のポートでインスタンスを再起動します。
接続の問題の詳細については、「[Amazon RDS DB インスタンスに接続できない](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)」を参照してください。
# MariaDB DB インスタンス接続の保護
MariaDB DB インスタンスのセキュリティを管理できます。
**Topics**
+ [Amazon RDS での MariaDB のセキュリティ](MariaDB.Concepts.UsersAndPrivileges.md)
+ [RDS for MariaDB のパスワード検証プラグインの使用](MariaDB.Concepts.PasswordValidationPlugins.md)
+ [SSL/TLS を使用した Amazon RDS 上の MariaDB DB インスタンスへのクライアント接続の暗号化](mariadb-ssl-connections.md)
+ [新しい SSL/TLS 証明書を使用して MariaDB インスタンスに接続するようにアプリケーションを更新する](ssl-certificate-rotation-mariadb.md)
# Amazon RDS での MariaDB のセキュリティ
MariaDB DB インスタンスのセキュリティは以下の 3 つのレベルで管理されます。
+ AWS Identity and Access Management では、どのユーザーが DB インスタンスに対して Amazon RDS の管理アクションを実行できるかを制御します。IAM 認証情報を使用して AWS に接続している場合、IAM アカウントには、Amazon RDS の管理オペレーションを実行するためのアクセス許可を付与する IAM ポリシーが必要です。(詳しくは、「[Amazon RDS での Identity and Access Management](UsingWithRDS.IAM.md)」を参照してください。)
+ DB インスタンスを作成するときは、VPC セキュリティグループを使用して、どのデバイスまたは Amazon EC2 インスタンスが DB インスタンスのエンドポイントとポートへの接続を開くことができるかを制御します。これらの接続は、Secure Socket Layer (SSL) と Transport Layer Security (TLS) を使用して行います。さらに、会社のファイアウォールルールでも、社内のどのデバイスが DB インスタンスへの接続を開くことができるかを制御できます。
+ MariaDB DB インスタンスへの接続が開かれたら、ログイン認証とアクセス許可は MariaDB のスタンドアロンインスタンスの場合と同じ方法で適用されます。`CREATE USER`、`RENAME USER`、`GRANT`、`REVOKE`、`SET PASSWORD` などのコマンドは、スタンドアロンデータベースの場合と同じ方法で、データベーススキーマテーブルを直接変更します。
Amazon RDS DB インスタンスを作成すると、マスターユーザーには以下のデフォルト権限が付与されます。
+ `alter`
+ `alter routine`
+ `create`
+ `create routine`
+ `create temporary tables`
+ `create user`
+ `create view`
+ `delete`
+ `drop`
+ `event`
+ `execute`
+ `grant option`
+ `index`
+ `insert`
+ `lock tables`
+ `process`
+ `references`
+ `reload`
この権限は MariaDB DB インスタンスに限定されます。`FLUSH LOGS` オペレーションまたは `FLUSH TABLES WITH READ LOCK` オペレーションにはアクセスを許可しません。
+ `replication client`
+ `replication slave`
+ `select`
+ `show create routine`
この権限は、バージョン 11.4 以降を実行している MariaDB DB インスタンスに限定されます。
+ `show databases`
+ `show view`
+ `trigger`
+ `update`
これらの権限の詳細については、MariaDB ドキュメントの「[User Account Management](http://mariadb.com/kb/en/mariadb/grant/)」を参照してください。
**注記**
DB インスタンスのマスターユーザーを削除することはできますが、お勧めはしません。マスターユーザーを再作成するには、`ModifyDBInstance` API または `modify-db-instance` AWS CLI を使用して、新しいマスターユーザーのパスワードを該当するパラメータで指定します。インスタンスに既存のマスターユーザーがない場合、指定したパスワードを使用してマスターユーザーが作成されます。
各 DB インスタンスに管理サービスを提供するために、DB インスタンスの作成時に `rdsadmin` ユーザーが作成されます。`rdsadmin` アカウントの権限をドロップ、名前変更、パスワード変更、または変更しようとするとエラーになります。
DB インスタンスの管理を可能にするために、スタンダード的なコマンド `kill` と `kill_query` の使用は制限されています。Amazon RDS コマンド `mysql.rds_kill`、`mysql.rds_kill_query`、`mysql.rds_kill_query_id` が MariaDB と MySQL 用に用意されており、DB インスタンスのユーザーセッションやクエリを終了できます。
# RDS for MariaDB のパスワード検証プラグインの使用
RDS for MariaDB バージョン 11.4 以降では、以下のパスワード検証プラグインを使用して、データベース接続のセキュリティを強化できます。
+ [simple\$1password\$1check](https://mariadb.com/kb/en/simple-password-check-plugin/) – パスワードに特定のタイプの文字が少なくとも特定の数だけ含まれているかどうかを確認します。
+ [cracklib\$1password\$1check](https://mariadb.com/kb/en/cracklib_password_check/) – パスワードが [CrackLib](https://github.com/cracklib/cracklib) ライブラリの辞書ファイルに表示されるかどうかを確認します。
これらのプラグインを有効にするには、DB インスタンスに関連付けられた DB パラメータグループでパラメータ `simple_password_check` または `cracklib_password_check` の値を `FORCE_PLUS_PERMANENT` に設定します。この値を設定すると、ランタイムに `UNINSTALL PLUGIN` ステートメントを使用してプラグインをアンインストールすることはできません。
これらのプラグインを無効にするには、DB インスタンスに関連付けられた DB パラメータグループでパラメータ `simple_password_check` または `cracklib_password_check` の値を `OFF` に設定します。この値を設定すると、プラグイン検証ルールは新しいパスワードには適用されません。
パラメータグループ内のパラメータの値の設定については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
# SSL/TLS を使用した Amazon RDS 上の MariaDB DB インスタンスへのクライアント接続の暗号化
Secure Sockets Layer (SSL) は、クライアントとサーバー間のネットワーク接続を安全に保つための業界標準のプロトコルです。SSL バージョン 3.0 以降では、名前が Transport Layer Security (TLS) に変更されています。Amazon RDS は、MariaDB DB インスタンス向けに SSL/TLS での暗号化をサポートしています。SSL/TLS を使用して、アプリケーションクライアントと MariaDB インスタンス間の接続を暗号化できます。SSL/TLS サポートは、すべての AWS リージョン で提供されています。
Amazon RDS を使用すると、SSL/TLS を使用して MariaDB DB インスタンスへのクライアント接続を暗号化し、MariaDB DB インスタンスへのすべての接続に SSL/TLS を要求し、MySQL コマンドラインクライアントから SSL/TLS (暗号化) を使用して接続することで、転送中のデータを保護できます。以下のセクションでは、Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS 暗号化の設定と使用に関するガイダンスを提供します。
**Topics**
+ [Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS サポート](MariaDB.Concepts.SSLSupport.md)
+ [Amazon RDS の MariaDB DB インスタンスへの特定のユーザーアカウントに SSL/TLS を要求する](MariaDB-ssl-connections.require-ssl-users.md)
+ [Amazon RDS 上の MariaDB DB インスタンスへのすべての接続に SSL/TLS を要求する](mariadb-ssl-connections.require-ssl.md)
+ [MySQL コマンドラインクライアントからの SSL/TLS による Amazon RDS 上の MariaDB DB インスタンスへの接続 (暗号化）](USER_ConnectToMariaDBInstanceSSL.CLI.md)
# Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS サポート
Amazon RDS によって、Amazon RDS によるインスタンスのプロビジョニング時、SSL/TLS 証明書が作成され、DB インスタンスにインストールされます。これらの証明書は認証局によって署名されます。SSL/TLS 証明書には、なりすまし攻撃から保護するために、SSL/TLS 証明書の共通名 (CN) として DB インスタンスのエンドポイントが含まれています。
Amazon RDS によって作成された SSL/TLS 証明書は信頼されたルートエンティティであり、ほとんどの場合は使用できますが、アプリケーションが証明書チェーンを受け入れていない場合は使用できない可能性があります。アプリケーションが証明書チェーンを受け入れていない場合は、中間証明書を使用して AWS リージョンに接続してみてください。例えば、SSL/TLS を使用して AWS GovCloud (US) リージョンに接続するには、中間証明書を使用する必要があります。
証明書のダウンロードについては、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。MySQL での SSL/TLS の使用の詳細については、「[新しい SSL/TLS 証明書を使用して MariaDB インスタンスに接続するようにアプリケーションを更新する](ssl-certificate-rotation-mariadb.md)」を参照してください。
Amazon RDS for MariaDB は、Transport Layer Security (TLS) バージョン 1.3、1.2、1.1、および 1.0 をサポートしています。TLS のサポートは MariaDB のバージョンによって異なります。次の表は、MariaDB バージョンの TLS サポートを示しています。
| TLS バージョン | MariaDB 11.8 | MariaDB 11.4 | MariaDB 10.11 | MariaDB 10.6 | MariaDB 10.5 | MariaDB 10.4 |
| --- | --- | --- | --- | --- | --- | --- |
| TLS 1.3 | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン |
| TLS 1.2 | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン | すべてのマイナーバージョン |
| TLS 1.1 | サポートされません | サポートされません | サポートされません | 10.6.16 以前 | 10.5.23 以前 | 10.4.32 以前 |
| TLS 1.0 | サポートされません | サポートされません | サポートされません | 10.6.16 以前 | 10.5.23 以前 | 10.4.32 以前 |
# Amazon RDS の MariaDB DB インスタンスへの特定のユーザーアカウントに SSL/TLS を要求する
Amazon RDS 上の MariaDB DB インスタンスへの特定のユーザーアカウント接続に SSL/TLS 暗号化を要求できます。機密情報を不正アクセスや傍受から保護することは、データの機密性が懸念される場合にセキュリティポリシーを適用する上で非常に重要です。
特定のユーザーのアカウントに SSL/TLS 接続を要求するには、MySQL のバージョンに応じて、次のいずれかのステートメントを使用して、ユーザーアカウントの `encrypted_user` に SSL/TLS 接続を要求します。
これを行うには、以下のステートメントを実行します。
```
ALTER USER 'encrypted_user'@'%' REQUIRE SSL;
```
MariaDB での SSL/TLS 接続の詳細については、MariaDB ドキュメントの「[Securing Connections for Client and Server](https://mariadb.com/kb/en/securing-connections-for-client-and-server/)」(クライアントとサーバーの接続の保護) を参照してください。
# Amazon RDS 上の MariaDB DB インスタンスへのすべての接続に SSL/TLS を要求する
MariaDB DB インスタンスへのすべてのユーザー接続が SSL/TLS を使用することを、`require_secure_transport` パラメータを使用して要求します。バージョン 11.4 以前では、`require_secure_transport` パラメータはデフォルトで `OFF` に設定されています。11.8 以降のバージョンでは、デフォルト値は `ON` に設定され、DB インスタンスへの接続に SSL/TLS が適用されます。非セキュア接続が必要な場合は、`require_secure_transport` パラメータを `OFF` に変更できます。
**注記**
`require_secure_transport` パラメーターは、MariaDB バージョン 10.5 以降でのみサポートされます。
`require_secure_transport` パラメータの値は、DB インスタンスの DB パラメータグループを更新することで設定できます。変更を有効にするために、DB インスタンスを再起動する必要はありません。
DB インスタンスに対して `require_secure_transport` パラメータが `ON` に設定されている場合、データベースクライアントが暗号化された接続を確立できれば、データベースクライアントはそのクラスターに接続できます。それ以外の場合は、次のようなエラーメッセージがクライアントに返されます。
```
ERROR 1045 (28000): Access denied for user 'USER'@'localhost' (using password: YES | NO)
```
パラメータの設定の詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
`require_secure_transport` パラメータの詳細については、[MMariaDB のドキュメント](https://mariadb.com/docs/ent/ref/mdb/system-variables/require_secure_transport/)を参照してください。
# MySQL コマンドラインクライアントからの SSL/TLS による Amazon RDS 上の MariaDB DB インスタンスへの接続 (暗号化）
MySQL 5.7 バージョン、MySQL 8.0 バージョン、または MariaDB バージョンを使用している場合は、`mysql` クライアントプログラムのパラメータが若干異なります。
使用しているバージョンを確認するには、`--version` オプションを指定しながら `mysql` コマンドを実行します。次の例の出力では、MariaDB のクライアントプログラムが使用されていることが確認できます。
```
$ mysql --version
mysql Ver 15.1 Distrib 10.5.15-MariaDB, for osx10.15 (x86_64) using readline 5.1
```
Amazon Linux、CentOS、SUSE、Debianなど、ほとんどのLinux ディストリビューションでは、MySQL をMariaDB に置き換えており、`mysql` バージョンは MariaDB と同じものを使用しています。
SSL/TLS を使用して DB インスタンスに接続するには、以下のステップを実行します。
**MySQL コマンドラインクライアントを使用して SSL/TLS で DB インスタンスに接続するには**
1. すべての AWS リージョン で使用できるルート証明書をダウンロードします。
証明書のダウンロードについては、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。
1. MySQL コマンドラインクライアントを使用して、SSL/TLS 暗号化を使用して DB インスタンスに接続します。`-h` パラメータは、DB インスタンスの DNS 名 (エンドポイント) に置き換えます。`--ssl-ca` パラメータは、必要に応じて SSL/TLS 証明書のファイル名に置き換えます。`-P` パラメータは、使用中の DB インスタンスのポートに置き換えます。`-u` パラメータでは、マスターユーザーなどの有効なデータベースユーザーのユーザー名に置き換えます。プロンプトが表示されたら、マスターユーザーパスワードを入力します。
次の例は、MariaDB で `--ssl-ca` パラメータを使用しながら、クライアントを起動する方法を示しています。
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl -P 3306 -u myadmin -p
```
SSL/TLS 接続で DB インスタンスのエンドポイントを SSL/TLS 証明書のエンドポイントと照合することを義務付けるには、次のコマンドを入力します。
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-verify-server-cert -P 3306 -u myadmin -p
```
次の例は、MySQL 5.7 以降で `--ssl-ca` パラメータを使用しながら、クライアントを起動する方法を示しています。
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=REQUIRED -P 3306 -u myadmin -p
```
1. プロンプトが表示されたら、マスターユーザーパスワードを入力します。
次のような出力が表示されます。
```
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 10.6.10-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
```
# 新しい SSL/TLS 証明書を使用して MariaDB インスタンスに接続するようにアプリケーションを更新する
2023 年 1 月 13 日に Amazon RDS は、Secure Socket Layer または Transport Layer Security (SSL/TLS) を使用して RDS DB インスタンスに接続するための新しい認証局 (CA) 証明書を公開しました。ここでは、新しい証明書を使用するためのアプリケーションの更新について説明します。
このトピックでは、アプリケーションが DB インスタンスに接続するために証明書認証が必要かどうかを判断できます。
**注記**
一部のアプリケーションは、サーバー上の証明書を正常に検証できる場合にのみ、MariaDB に接続されるように設定されています。そのようなアプリケーションの場合は、新しい CA 証明書を含むように、クライアントアプリケーションの信頼ストアを更新する必要があります。
`disabled`、`preferred`、および `required` の SSL モードを指定できます。`preferred` SSL モードを使用し、CA 証明書が存在しないか、最新でない場合、接続は SSL を使用しない状態にフォールバックし、正常に接続します。
`preferred` モードの使用を避けることをお勧めします。`preferred` モードでは、接続時に無効な証明書が検出されると、暗号化の使用が停止し、暗号化せずに続行されます。
クライアントアプリケーションの信頼ストアで CA 証明書を更新した後、DB インスタンスで証明書をローテーションできます。これらの手順を開発環境またはステージング環境でテストしてから、本番環境で実装することを強くお勧めします。
証明書のローテーションの詳細については、「[SSL/TLS 証明書のローテーション](UsingWithRDS.SSL-certificate-rotation.md)」を参照してください。証明書のダウンロードの詳細については、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。MariaDB DB インスタンスで SSL/TLS を使用する方法については、「[Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS サポート](MariaDB.Concepts.SSLSupport.md)」を参照してください。
**Topics**
+ [クライアントが接続するために証明書の検証を必要とするかどうかの確認](#ssl-certificate-rotation-mariadb.determining)
+ [アプリケーション信頼ストアの更新](#ssl-certificate-rotation-mariadb.updating-trust-store)
+ [SSL 接続を確立するための Java コードの例](#ssl-certificate-rotation-mariadb.java-example)
## クライアントが接続するために証明書の検証を必要とするかどうかの確認
JDBC クライアントおよび MySQL クライアントを接続するために証明書の検証が必要かどうかを確認できます。
### JDBC
MySQL Connector/J 8.0 を使用した次の例では、アプリケーションの JDBC 接続プロパティをチェックして、正常な接続に有効な証明書が必要かどうかを確認する 1 つの方法を示します。MySQL のすべての JDBC 接続オプションの詳細については、MySQL ドキュメントの「[設定プロパティ](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html)」を参照してください。
MySQL Connector/J 8.0 を使用するとき、次の例のように、接続プロパティで `sslMode` が `VERIFY_CA` または `VERIFY_IDENTITY` に設定されている場合、SSL 接続にはサーバー CA 証明書に対する検証が必要です。
```
Properties properties = new Properties();
properties.setProperty("sslMode", "VERIFY_IDENTITY");
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
```
**注記**
MySQL Java Connector v5.1.38 以降または MySQL Java Connector v8.0.9 以降を使用してデータベースに接続する場合、データベースへの接続時に SSL/TLS を使用するようにアプリケーションを明示的に設定しなくても、これらのクライアントドライバーはデフォルトで SSL/TLS を使用します。また、SSL/TLS の使用時に証明書検証が部分的に実行され、データベースサーバー証明書の有効期限が切れていると、接続に失敗します。
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
### MySQL
MySQL クライアントの以下の例では、スクリプトの MySQL 接続をチェックして、正常な接続に有効な証明書が必要かどうかを確認する 2 つの方法を示します。MySQL クライアントで使用するすべての接続オプションの詳細については、MySQL ドキュメントの「[ Client-Side Configuration for Encrypted Connections](https://dev.mysql.com/doc/refman/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)」を参照してください。
MySQL 5.7 または MySQL 8.0 クライアントを使用するとき、次の例のように、`--ssl-mode` オプションに `VERIFY_CA` または `VERIFY_IDENTITY` を指定する場合、SSL 接続にはサーバー CA 証明書に対する検証が必要です。
```
mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-mode=VERIFY_CA
```
MySQL 5.6 クライアントを使用するとき、次の例のように、`--ssl-verify-server-cert` オプションを指定する場合、SSL 接続にはサーバー CA 証明書に対する検証が必要です。
```
mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-verify-server-cert
```
## アプリケーション信頼ストアの更新
MySQL アプリケーションの信頼ストアの更新の詳細については、MariaDB ドキュメントの「[Using TLS/SSL with MariaDB Connector/J](https://mariadb.com/kb/en/library/using-tls-ssl-with-mariadb-java-connector/)を参照してください。
ルート証明書のダウンロードについては、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。
証明書をインポートするサンプルスクリプトについては、[証明書を信頼ストアにインポートするためのサンプルスクリプト](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script) を参照してください。
**注記**
信頼ストアを更新するとき、新しい証明書を追加できるだけでなく、古い証明書を保持できます。
アプリケーションで MariaDB コネクタ/J JDBC ドライバーを使用している場合は、アプリケーションで以下のプロパティを設定します。
```
System.setProperty("javax.net.ssl.trustStore", certs);
System.setProperty("javax.net.ssl.trustStorePassword", "password");
```
アプリケーションを起動するとき、以下のプロパティを設定します。
```
java -Djavax.net.ssl.trustStore=/path_to_truststore/MyTruststore.jks -Djavax.net.ssl.trustStorePassword=my_truststore_password com.companyName.MyApplication
```
**注記**
セキュリティ上のベストプラクティスとして、ここに表示されているプロンプト以外のパスワードを指定してください。
## SSL 接続を確立するための Java コードの例
次のコード例は、JDBC を使用する SSL 接続のセットアップ方法を示します。
```
private static final String DB_USER = "admin";
private static final String DB_USER = "user name";
private static final String DB_PASSWORD = "password";
// This key store has only the prod root ca.
private static final String KEY_STORE_FILE_PATH = "file-path-to-keystore";
private static final String KEY_STORE_PASS = "keystore-password";
public static void main(String[] args) throws Exception {
Class.forName("org.mariadb.jdbc.Driver");
System.setProperty("javax.net.ssl.trustStore", KEY_STORE_FILE_PATH);
System.setProperty("javax.net.ssl.trustStorePassword", KEY_STORE_PASS);
Properties properties = new Properties();
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
Connection connection = DriverManager.getConnection("jdbc:mysql://ssl-mariadb-public.cni62e2e7kwh.us-east-1.rds.amazonaws.com:3306?useSSL=true",properties);
Statement stmt=connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 1 from dual");
return;
}
```
**重要**
データベース接続で SSL/TLS を使用することを決定し、アプリケーションの信頼ストアを更新したら、rds-ca-rsa2048-g1 証明書を使用するようにデータベースを更新できます。ステップについては、「[DB インスタンスまたはクラスターの変更による CA 証明書の更新](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating)」のステップ 3 を参照してください。
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
# Amazon RDS Optimized Reads による RDS for MariaDB のクエリパフォーマンスの向上
Amazon RDS Optimized Reads で RDS for MariaDB のクエリ処理を高速化することができます。RDS Optimized Reads を使用する RDS for MariaDB DB インスタンスは、これを使用しない DB インスタンスに比べて、クエリ処理を最大 2 倍高速化できます。
**Topics**
+ [RDS Optimized Reads の概要](#rds-optimized-reads-mariadb-overview)
+ [RDS Optimized Reads のユースケース](#rds-optimized-reads-mariadb-use-cases)
+ [RDS Optimized Reads のベストプラクティス](#rds-optimized-reads-mariadb-best-practices)
+ [RDS Optimized Reads の使用](#rds-optimized-reads-mariadb-using)
+ [RDS Optimized Reads を使用する DB インスタンスのモニタリング](#rds-optimized-reads-mariadb-monitoring)
+ [RDS Optimized Reads についての制限事項](#rds-optimized-reads-mariadb-limitations)
## RDS Optimized Reads の概要
RDS Optimized Reads が有効になっている RDS for MariaDB DB インスタンスを使用する場合、DB インスタンスはインスタンスストアを使用することで、より高速なクエリパフォーマンスを達成します。*インスタンスストア*は、DB インスタンスに一時ブロックレベルのストレージを提供します。ストレージは、ホストサーバーに物理的にアタッチされた不揮発性メモリエクスプレス (NVMe) によるソリッドステートドライブ (SSD) にあります。このストレージは、低レイテンシー、優れたランダム I/O パフォーマンス、高いシーケンシャル読み取りスループットを実現するために最適化されています。
DB インスタンスが db.m5d や db.m6gd などのインスタンスストアを含む DB インスタンスクラスを使用する場合、RDS Optimized Reads はデフォルトで有効になっています。RDS Optimized Reads では、一部の一時オブジェクトがインスタンスストアに保存されます。これらの一時オブジェクトには、内部一時ファイル、内部オンディスク一時テーブル、メモリマップファイル、バイナリログ (binlog) キャッシュファイルが含まれます。インスタンスストアの詳細については、*Linux インスタンス向け Amazon Elastic Compute Cloud ユーザーガイド*の「[Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)」を参照してください。
MariaDB でクエリ処理用の一時オブジェクトを生成するワークロードは、インスタンスストアを利用してクエリ処理を高速化できます。このタイプのワークロードには、ソート、ハッシュ集約、高負荷結合、共通テーブル式 (CTE)、インデックス付けされていない列に対するクエリが含まれます。これらのインスタンスストアボリュームによって、永続的な Amazon EBS ストレージに使用されるストレージ設定に関係なく、より高い IOPS とパフォーマンスを提供します。RDS Optimized Reads は一時オブジェクトのオペレーションをインスタンスストアにオフロードするため、永続的ストレージ (Amazon EBS) の 1 秒あたりの入出力オペレーション (IOPS) またはスループットを、永続オブジェクトのオペレーションに使用できるようになりました。これらのオペレーションには、通常のデータファイルの読み取りと書き込み、フラッシュやバッファ挿入のマージなどのバックグラウンドエンジンオペレーションが含まれます。
**注記**
手動の RDS スナップショットと自動の RDS スナップショットの両方に含まれているのは、永続オブジェクトのエンジンファイルのみです。インスタンスストアで作成された一時オブジェクトは RDS スナップショットには含まれません。
## RDS Optimized Reads のユースケース
クエリの実行を内部テーブルやファイルなどの一時オブジェクトに大きく依存するワークロードがある場合は、RDS Optimized Reads を有効にすると便利です。RDS Optimized Reads の候補となるユースケースは次のとおりです。
+ 複雑なテーブル共通式 (CTE)、派生テーブル、グループ化オペレーションを使用して分析クエリを実行するアプリケーション
+ 最適化されていないクエリで大量の読み取りトラフィックを処理するリードレプリカ
+ `GROUP BY` 句や `ORDER BY` 句を含むクエリなど、複雑なオペレーションを伴うオンデマンドまたは動的レポートクエリを実行するアプリケーション
+ クエリ処理に内部テンポラリテーブルを使用するワークロード
エンジンステータス変数 `created_tmp_disk_tables` をモニタリングすることで、DB インスタンスに作成されたディスクベースの一時テーブルの数を判断できます。
+ 中間結果を格納するために、直接またはプロシージャ内で大規模な一時テーブルを作成するアプリケーション
+ インデックス付けされていない列をグループ化または順序付けするデータベースクエリ
## RDS Optimized Reads のベストプラクティス
RDS Optimized Reads を使用するベストプラクティスは次のとおりです。
+ インスタンスストアが実行中にストレージ不足によって失敗した場合に備えて、読み取り専用クエリの再試行ロジックを追加します。
+ CloudWatch メトリクスの `FreeLocalStorage` を使用して、インスタンスストアで使用可能なストレージ容量をモニタリングします。DB インスタンスのワークロードが原因でインスタンスストアが上限に達している場合は、より大きな DB インスタンスクラスを使用するように DB インスタンスを変更します。
+ DB インスタンスに十分なメモリがあるのにインスタンスストアのストレージ制限に達している場合は、`binlog_cache_size` 値を増やしてセッション固有のバイナリログエントリをメモリに保持します。この設定により、ディスク上の一時バイナリログキャッシュファイルにバイナリログエントリの書き込みを防止します。
`binlog_cache_size` パラメータはセッション固有です。この値は、新しいセッションごとに変更できます。このパラメータを設定すると、ピーク負荷時に DB インスタンスのメモリ使用量が増加する可能性があります。そのため、アプリケーションのワークロードのパターンと DB インスタンスで使用可能なメモリに基づいてパラメータ値を増やすことを検討してください。
+ `binlog_format` には `MIXED` のデフォルト値を使用します。トランザクションのサイズによっては、`binlog_format` を `ROW` に設定すると、インスタンスストアのバイナリログキャッシュファイルが大きくなる可能性があります。
+ 1 つのトランザクションで大量の変更を実行することは避けてください。このような種類のトランザクションでは、インスタンスストアに大きなバイナリログキャッシュファイルが生成され、インスタンスストアが満杯になると問題が発生する可能性があります。バイナリログキャッシュファイルのストレージ使用量を最小限に抑えるために、書き込みを複数の小さなトランザクションに分割することを検討してください。
## RDS Optimized Reads の使用
シングル AZ DB インスタンスデプロイまたはマルチ AZ DB インスタンスデプロイで、次の DB インスタンスクラスのいずれかを使用して RDS for MariaDB DB インスタンスをプロビジョニングすると、DB インスタンスは自動的に RDS Optimized Reads を使用します。
RDS Optimized Reads をオンにするには、次のいずれかの操作を行います。
+ これらの DB インスタンスクラスの 1 つを使用して、RDS for MariaDB DB インスタンスを作成します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ これらの DB インスタンスクラスの 1 つを使用して、既存の RDS for MariaDB DB インスタンスを変更します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
RDS Optimized Reads は、ローカル NVMe SSD ストレージのある DB インスタンスクラスの 1 つ以上がサポートされているすべての AWS リージョン で使用できます。DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
DB インスタンスクラスの可用性は AWS リージョン によって異なります。DB インスタンスクラスが特定の AWS リージョン でサポートされているかどうかを判断するには、「[AWS リージョン での DB インスタンスクラスのサポートを決定する](Concepts.DBInstanceClass.RegionSupport.md)」を参照してください。
RDS Optimized Reads を使用しない場合は、この機能をサポートする DB インスタンスクラスを使用しないように DB インスタンスを変更してください。
## RDS Optimized Reads を使用する DB インスタンスのモニタリング
RDS Optimized Reads を使用する DB インスタンスは、次の CloudWatch メトリクスでモニタリングできます。
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
これらのメトリクスでは、利用可能なインスタンスストアストレージ、IOPS、スループットに関するデータを提供します。これらのメトリクスの詳細については、「」を参照してください。[Amazon RDS の Amazon CloudWatch インスタンスレベルのメトリクス](rds-metrics.md#rds-cw-metrics-instance)
## RDS Optimized Reads についての制限事項
RDS Optimized Reads には次の制限事項が適用されます。
+ RDS Optimized Reads は、以下の RDS for MariaDB バージョンでサポートされています。
+ 11.4 以降のメジャーリリースで利用可能なすべてのマイナーバージョン
+ 10.11.4 以降の 10.11 バージョン
+ 10.6.7 以上の 10.6 バージョン
+ 10.5.16 以上の 10.5 バージョン
+ 10.4.25 以上の 10.4 バージョン
RDS for MariaDB のバージョンの詳細については、「[Amazon RDS の MariaDB のバージョン](MariaDB.Concepts.VersionMgmt.md)」を参照してください。
+ RDS Optimized Reads をサポートする DB インスタンスクラスでは、一時オブジェクトの場所を永続ストレージ (Amazon EBS) に変更することはできません。
+ DB インスタンスでバイナリロギングが有効になっている場合、最大トランザクションサイズはインスタンスストアのサイズによって制限されます。MariaDB では、`binlog_cache_size` の値よりも多くのストレージを必要とするセッションでは、インスタンスストアに作成される一時的なバイナリログキャッシュファイルにトランザクションの変更が書き込まれます。
+ トランザクションは、インスタンスストアが満杯になるとエラーになる可能性があります。
# Amazon RDS Optimized Writes for MariaDB による書き込みパフォーマンスの向上
RDS Optimized Writes for MariaDB によって、書き込みトランザクションのパフォーマンスを向上させることができます。RDS for MariaDB データベースで RDS Optimized Writes を使用すると、書き込みトランザクションのスループットが最大 2 倍向上します。
**Topics**
+ [RDS Optimized Writes の概要](#rds-optimized-writes-overview)
+ [RDS Optimized Writes の使用](#rds-optimized-writes-using-mariadb)
+ [既存のデータベースで RDS Optimized Writes を有効にする](#rds-optimized-writes-modify-enable-mariadb)
+ [RDS Optimized Writes についての制限事項](#rds-optimized-writes-limitations-mariadb)
## RDS Optimized Writes の概要
RDS Optimized Writes を有効にすると、RDS for MariaDB データベースは、データを耐久性のあるストレージにフラッシュするときに、二重書き込みバッファを必要とせずに一度だけ書き込みます。データベースは、ACID プロパティ保護機能の提供を継続することで、信頼性の高いデータベーストランザクションを実現するとともに、パフォーマンスを向上させます。
MariaDB のようなリレーショナルデータベースには、原子性、一貫性、分離性、耐久性という *ACID 特性*があり、信頼性の高いデータベーストランザクションを実現できます。これらの特性を発揮するために、MariaDB は部分的なページ書き込みエラーを防ぐ*二重書き込みバッファ*と呼ばれるデータストレージ領域を使用しています。これらのエラーは、データベースがページを更新中に、停電時などのハードウェア障害が発生した場合に発生します。MariaDB データベースは、部分的なページ書き込みを検出し、二重書き込みバッファ内のページのコピーによって回復できます。この手法で保護が可能ですが、余分な書き込みオペレーションも必要になります。MariaDB の二重書き込みバッファの詳細については、MariaDB ドキュメントの「[InnoDB Doublewrite Buffer](https://mariadb.com/kb/en/innodb-doublewrite-buffer/)」(InnoDB 二重書き込みバッファ) を参照してください。
RDS Optimized Writes を有効にすると、RDS for MariaDB データベースは、データを耐久性のあるストレージにフラッシュするときに、二重書き込みバッファを使用せずに一度だけ書き込みます。RDS Optimized Writes は、RDS for MariaDB データベースで書き込みの多いワークロードを実行する場合に便利です。書き込みワークロードの高いデータベースの例としては、デジタル決済、金融取引、ゲームアプリケーションに対応したデータベースなどがあります。
これらのデータベースは、AWS Nitro System を使用する DB インスタンスクラスで実行されます。これらのシステムのハードウェア構成により、データベースは 16 KiB ページを 1 ステップで確実かつ永続的にデータファイルに直接書き込むことができます。AWS Nitro System により RDS Optimized Writes が可能になります。
新しいデータベースパラメータ `rds.optimized_writes` を設定して、RDS for MariaDB データベースの RDS Optimized Writes 機能を制御できます。RDS for MariaDB の場合、次のバージョンの DB パラメータグループのこのパラメータにアクセスします。
+ 11.8 以降のメジャーリリースで利用可能なすべてのマイナーバージョン
+ 14.4.3 以降の 11.4 バージョン
+ 10.11.4 以降の 10.11 バージョン
+ 10.6.10 以降の 10.6 バージョン
次の値を使用してパラメータを設定します。
+ `AUTO` – データベースが RDS Optimized Writes をサポートしている場合は有効にします。データベースが RDS Optimized Writes をサポートしていない場合は無効にします。この設定はデフォルトです。
+ `OFF` – データベースが RDS Optimized Writes をサポートしている場合でも無効にします。
RDS Optimized Writes を使用するように設定されている RDS for MariaDB データベースを、この機能をサポートしていない DB インスタンスクラスに移行した場合、RDS はそのデータベースの RDS Optimized Writes を自動的に無効にします。
RDS Optimized Writes を無効にすると、データベースは MariaDB の二重書き込みバッファを使用します。
RDS for MariaDB データベースが RDS Optimized Writes を使用しているかどうかを判断するには、データベースの `innodb_doublewrite` パラメータの現在の値を表示します。データベースが RDS Optimized Writes を使用している場合、このパラメータは `FALSE` (`0`) に設定されています。
## RDS Optimized Writes の使用
RDS コンソール、AWS CLI、または RDS API を使用して RDS for MariaDB データベースを作成すると、RDS Optimized Writes を有効にできます。RDS Optimized Writes は、データベース作成時に、次の条件に両方当てはまる場合、自動的に有効になります。
+ RDS Optimized Writes をサポートする DB エンジンのバージョンと DB インスタンスクラスを指定します。
+ RDS Optimized Writes は、以下の RDS for MariaDB バージョンでサポートされています。
+ 11.8 以降のメジャーリリースで利用可能なすべてのマイナーバージョン
+ 14.4.3 以降の 11.4 バージョン
+ 10.11.4 以降の 10.11 バージョン
+ 10.6.10 以降の 10.6 バージョン
RDS for MariaDB のバージョンの詳細については、「[Amazon RDS の MariaDB のバージョン](MariaDB.Concepts.VersionMgmt.md)」を参照してください。
+ RDS Optimized Writes は、次の DB インスタンスクラスを使用する RDS for MariaDB データベースでサポートされています。
+ db.m7i
+ db.m7g
+ db.m6g
+ db.m6gd
+ db.m6i
+ db.m5
+ db.m5d
+ db.r7i
+ db.r7g
+ db.r6g
+ db.r6gd
+ db.r6i
+ db.r5
+ db.r5b
+ db.r5d
+ db.x2idn
+ db.x2iedn
DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
DB インスタンスクラスの可用性は AWS リージョン によって異なります。DB インスタンスクラスが特定の AWS リージョン でサポートされているかどうかを判断するには、「[AWS リージョン での DB インスタンスクラスのサポートを決定する](Concepts.DBInstanceClass.RegionSupport.md)」を参照してください。
+ データベースに関連付けられたパラメータグループでは、`rds.optimized_writes` パラメータが `AUTO` に設定されます。デフォルトのパラメータグループでは、このパラメータは常に `AUTO` に設定されます。
RDS Optimized Writes をサポートする DB エンジンバージョンと DB インスタンスクラスを使用し、この機能は使用しない場合は、データベースの作成時に、カスタムパラメータグループを指定します。このパラメータグループで、`rds.optimized_writes` パラメータを `OFF` に設定します。その後、データベースで RDS Optimized Writes を使用するには、パラメータを `AUTO` に設定して有効にすることができます。カスタムパラメータグループの作成とパラメータの設定については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
### コンソール
RDS コンソールを使用して RDS for MariaDB データベースを作成すると、RDS Optimized Writes をサポートする DB エンジンバージョンと DB インスタンスクラスをフィルタリングできます。フィルタリングを有効にすると、利用可能な DB エンジンのバージョンと DB インスタンスクラスから選択できるようになります。
RDS Optimized Writes をサポートする DB エンジンバージョンを選択するには、**エンジンバージョン**をサポートする RDS for MariaDB DB のエンジンバージョンをフィルタリングして、バージョンを選択します。
![\[[エンジンバージョン] の [エンジンオプション セクション。[Amazon RDS Optimized Writes] フィルターがオンになっています。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-version-filter-mariadb.png)
**[インスタンスの設定]** セクションで、RDS Optimized Writes をサポートする DB インスタンスクラスをフィルタリングして、DB インスタンスクラスを選択します。
![\[[DB インスタンスクラス] の [インスタンス設定] セクション。[Amazon RDS Optimized Writes] フィルターがオンになっています。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-class-filter.png)
これらの選択を行った後、要件を満たす他の設定を選択し、コンソールで RDS for MariaDB データベースの作成を完了します。
### AWS CLI
AWS CLI を使用して DB インスタンスを作成するには、[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) コマンドを実行します。`--engine-version` と `--db-instance-class` の値が RDS Optimized Writes をサポートしていることを確認してください。また、DB インスタンスに関連付けられたパラメータグループでは、`rds.optimized_writes` パラメータが`AUTO` に設定されていることを確認します。この例では、デフォルトパラメータグループを DB インスタンスに関連付けます。
**Example RDS Optimized Writes を使用する DB インスタンスの作成**
Linux、macOS、Unix の場合:
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --engine mariadb \
4. --engine-version 10.6.10 \
5. --db-instance-class db.r5b.large \
6. --manage-master-user-password \
7. --master-username admin \
8. --allocated-storage 200
```
Windows の場合:
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --engine mariadb ^
4. --engine-version 10.6.10 ^
5. --db-instance-class db.r5b.large ^
6. --manage-master-user-password ^
7. --master-username admin ^
8. --allocated-storage 200
```
### RDS API
[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) オペレーションを使用して、DB インスタンスを作成できます。このオペレーションを使用する際は、`EngineVersion` と `DBInstanceClass` の値が RDS Optimized Writes をサポートしていることを確認してください。また、DB インスタンスに関連付けられたパラメータグループでは、`rds.optimized_writes` パラメータが`AUTO` に設定されていることを確認します。
## 既存のデータベースで RDS Optimized Writes を有効にする
RDS Optimized Writes を有効にするために既存の RDS for MariaDB データベースを変更するには、サポート対象の DB エンジンバージョンと DB インスタンスクラスでデータベースを作成する必要があります。さらに、必要な基盤となるファイルシステム設定は、リリース前に作成されたデータベースの設定と互換性がないため、データベースは 2023 年 3 月 7 日に RDS Optimized Writes がリリースされた*後*に作成されたものでなければなりません。これらの条件が満たされている場合は、`rds.optimized_writes` パラメータを `AUTO` に設定して RDS Optimized Writes を有効にできます。
データベースが、サポートされているエンジンバージョン、インスタンスクラス、またはファイルシステム設定で作成されて*いない*場合、RDS ブルー/グリーンデプロイを使用して、サポートされている設定に移行できます。ブルー/グリーンデプロイを作成して、以下の操作を行います。
+ **[グリーンデータベースで Optimized Writes を有効にする]** を選択し、RDS Optimized Writes をサポートするエンジンバージョンと DB インスタンスクラスを指定します。サポートされているエンジンバージョンとインスタンスクラスのリストについては、「[RDS Optimized Writes の使用](#rds-optimized-writes-using-mariadb)」を参照してください。
+ **[ストレージ]** で、**[ストレージファイルシステム設定のアップグレード]** を選択します。このオプションは、データベースを互換性のある基本ファイルシステム設定にアップグレードします。
ブルー/グリーンデプロイを作成すると、`rds.optimized_writes` パラメータが `AUTO` に設定されている場合、RDS Optimized Writes がグリーン環境で自動的に有効になります。その後、ブルー/グリーンデプロイを切り替えて、グリーン環境を新しい本番環境に昇格できます。
詳細については、「[Amazon RDS でのブルー/グリーンデプロイの作成](blue-green-deployments-creating.md)」を参照してください。
## RDS Optimized Writes についての制限事項
RDS for MariaDB データベースをスナップショットから復元する場合、次の条件がすべて当てはまる場合のみ、データベースの RDS Optimized Writes を有効にできます。
+ スナップショットが RDS Optimized Writes をサポートするデータベースから作成された。
+ スナップショットは、RDS Optimized Writes のリリース*後に*作成されたデータベースから作成されました。
+ スナップショットが RDS Optimized Writes をサポートするデータベースに復元された。
+ 復元されたデータベースは、`AUTO` に設定された `rds.optimized_writes` パラメータに関連付けられています。
# MariaDB DB エンジンのアップグレード
新しいバージョンのデータベースエンジンが Amazon RDS でサポートされている場合は、DB インスタンスをその新しいバージョンにアップグレードできます。MariaDB DB インスタンスのアップグレードには、メジャーバージョンのアップグレードとマイナーバージョンのアップグレードの 2 種類あります。
*メジャーバージョンのアップグレード*には、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があります。そのため、DB インスタンスのメジャーバージョンアップグレードは手動で実行する必要があります。メジャーバージョンアップグレードをスタートするには、DB インスタンスを変更します。ただし、メジャーバージョンのアップグレードを行う前に、「[RDS for MariaDB のメジャーバージョンアップグレード](USER_UpgradeDBInstance.MariaDB.Major.md)」の手順を実行することをお勧めします。
それに対して、*マイナーバージョンのアップグレード*に含まれるのは、既存のアプリケーションとの下位互換性がある変更のみです。マイナーバージョンのアップグレードを手動でスタートするには、DB インスタンスを変更します。または、DB インスタンスの作成時または変更時に、[**Auto minor version upgrade (マイナーバージョン自動アップグレード)**] を有効にすることができます。これにより、Amazon RDS によって新しいバージョンがテストおよび承認されると、DB インスタンスが自動的にアップグレードされます。アップグレードの実行については、「[DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)」を参照してください。
ご使用の MariaDB DB インスタンスでリードレプリケーションを使用している場合は、ソースインスタンスのアップグレード前に、すべてのリードレプリカをアップグレードする必要があります。DB インスタンスがマルチ AZ 配置にある場合、プライマリとスタンバイのレプリカの両方がアップグレードされます。アップグレードが完了するまで、DB インスタンスは使用できない場合があります。
MariaDB でサポートされるバージョンおよびバージョン管理については、「[Amazon RDS の MariaDB のバージョン](MariaDB.Concepts.VersionMgmt.md)」を参照してください。
データベースエンジンをアップグレードするには、ダウンタイムが必要です。ダウンタイムの時間は、DB インスタンスのサイズによって異なります。
Amazon RDS は、複数のデータベースリソースと AWS アカウントにわたるマイナーバージョンの自動アップグレードを管理するためのアップグレードロールアウトポリシーもサポートしています。詳細については、「[自動マイナーバージョンアップグレードの AWS Organizations アップグレードロールアウトポリシーの使用](RDS.Maintenance.AMVU.UpgradeRollout.md)」を参照してください。
**ヒント**
ブルー/グリーンデプロイを使用することで、DB インスタンスのアップグレードに必要なダウンタイムを最小限に抑えることができます。詳細については、「[データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する](blue-green-deployments.md)」を参照してください。
**Topics**
+ [MariaDB のアップグレードに関する考慮事項](#USER_UpgradeDBInstance.MariaDB.Considerations)
+ [有効なアップグレードターゲットの検索](#USER_UpgradeDBInstance.MariaDB.FindingTargets)
+ [MariaDB のバージョン番号](USER_UpgradeDBInstance.MariaDB.VersionID.md)
+ [RDS for MariaDB の RDS バージョン番号](USER_UpgradeDBInstance.MariaDB.rds.version.md)
+ [RDS for MariaDB のメジャーバージョンアップグレード](USER_UpgradeDBInstance.MariaDB.Major.md)
+ [MariaDB DB インスタンスのアップグレード](#USER_UpgradeDBInstance.MariaDB.Upgrading)
+ [RDS for MariaDB のマイナーバージョンの自動アップグレード](USER_UpgradeDBInstance.MariaDB.Minor.md)
+ [RDS for MariaDB データベースをアップグレードするときにリードレプリカを使用してダウンタイムを短縮する](USER_UpgradeDBInstance.MariaDB.ReducedDowntime.md)
+ [イベントによる RDS for MariaDB DB エンジンのアップグレードのモニタリング](USER_UpgradeDBInstance.MariaDB.Monitoring.md)
## MariaDB のアップグレードに関する考慮事項
Amazon RDS によってアップグレードプロセス中に 2 つ以上の DB スナップショットが作成されます。Amazon RDS は、アップグレードを変更する*前に* DB インスタンスのスナップショットを最大 2 つ作成します。アップグレードがデータベースに対して機能しない場合は、これらのスナップショットの 1 つを復元して、以前のバージョンを実行する DB インスタンスを作成できます。Amazon RDS は、アップグレードが完了すると、DB インスタンスのもう 1 つのスナップショットを作成します。Amazon RDS は、AWS Backup が DB インスタンスのバックアップを管理するかどうかにかかわらず、これらのスナップショットを作成します。
**注記**
DB インスタンスのバックアップ保持期間を 0 より大きく設定した場合にのみ、Amazon RDS は DB スナップショットを作成します。バックアップ保持期間を変更するには、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
アップグレードが完了したら、データベースエンジンの前のバージョンに戻すことはできません。前のバージョンに戻す必要がある場合は、作成された初期の DB スナップショットを復元して、新しい DB インスタンスを作成します。
Amazon RDS でサポートされている新しいバージョンに DB インスタンスをアップグレードするタイミングを制御します。このレベルの管理によって、特定のデータベースのバージョンとの互換性を維持しながら、新しいバージョンを本稼働環境にデプロイする前にアプリケーションに対してテストできます。準備が整ったら、自分のスケジュールに最適なタイミングでバージョンアップグレードを実行できます。
ご使用の DB インスタンスでリードレプリカを使用している場合は、ソースインスタンスのアップグレード前に、すべてのリードレプリカをアップグレードする必要があります。
DB インスタンスがマルチ AZ 配置にある場合は、プライマリとスタンバイの両方の DB インスタンスがアップグレードされます。プライマリとスタンバイの DB インスタンスは同時にアップグレードされ、アップグレードが完了するまで停止します。停止時間は、データベースエンジン、エンジンのバージョン、DB インスタンスのサイズによって異なります。
## 有効なアップグレードターゲットの検索
AWS マネジメントコンソール を使用して DB インスタンスをアップグレードする場合、DB インスタンスの有効なアップグレードターゲットが表示されます。次の AWS CLI コマンドを実行して、DB インスタンスの有効なアップグレードターゲットを特定することもできます。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version version_number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version version_number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
例えば、MariaDB バージョン 10.5.15 DB インスタンスの有効なアップグレードターゲットを特定するには、次の AWS CLI コマンドを実行します。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version 10.5.17 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version 10.5.17 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# MariaDB のバージョン番号
RDS for MariaDB データベースエンジンのバージョン番号付けシーケンスは、*major.minor.patch.YYYYMMDD* または *major.minor.patch* の形式です。例えば、10.11.5.R2.20231201 または 10.4.30 です。使用される形式は、MariaDB エンジンのバージョンによって異なります。
**major**
メジャーバージョン番号は、10.11 など、バージョン番号の整数部分と 1 つ目の小数部分の両方です。メジャーバージョンのアップグレードでは、バージョン番号の主要な部分が大きくなります。例えば、*10.5*.20 から 10.6.12 へのアップグレードはメジャーバージョンのアップグレードであり、*10.5* と *10.6* はメジャーバージョン番号です。
**minor**
マイナーバージョン番号は、バージョン番号の 3 番目と 4 番目の部分です。例えば、10.11.5 の 5 です。
**patch**
パッチはバージョン番号の 4 番目の部分です。例えば、10.11.5.R2 の R2 です。RDS パッチバージョンには、リリース後にマイナーバージョンに追加された重要なバグ修正が含まれています。
**YYYYMMDD**
日付はバージョン番号の 5 番目の部分です。例えば、10.11.5.R2.20231201 の 20231201 です。RDS 日付バージョンは、リリース後にマイナーバージョンに追加された重要なセキュリティ修正を含むセキュリティパッチです。エンジンの動作を変更する可能性のある修正は含まれていません。
次の表に、RDS for MariaDB バージョン 10.11 の命名スキームを示します。
| 10.11 マイナーバージョン | 命名スキーム |
| --- | --- |
| ≥5 | 新しい DB インスタンスでは、*major.minor.patch.YYYMMDD *を使用します。例えば、10.11.5.R2.20231201。 既存の DB インスタンスは、次のメジャーバージョンまたはマイナーバージョンのアップグレードまで、10.11.5.R2 など、*major.minor.patch* を使用する場合があります。 |
| < 5 | 既存の DB インスタンスは、*major.minor.patch* を使用します。例えば、10.11.4.R2。 |
次の表に、RDS for MariaDB バージョン 10.6 の命名スキームを示します。
| 10.6 マイナーバージョン | 命名スキーム |
| --- | --- |
| ≥ 14 | 新しい DB インスタンスは、*major.minor.patch.YYYMMDD* を使用します。例えば、10.6.14.R2.20231201。 既存の DB インスタンスは、次のメジャーまたはマイナーバージョンのアップグレードまで、10.6.14.R2 など、*major.minor.patch* を使用する場合があります。 |
| < 14 | 既存の DB インスタンスは、*major.minor.patch* を使用します。例えば、10.6.13.R2。 |
次の表に、RDS for MariaDB バージョン 10.5 の命名スキームを示します。
| 10.5 マイナーバージョン | 命名スキーム |
| --- | --- |
| ≥ 21 | 新しい DB インスタンスは、*major.minor.patch.YYYMMDD* を使用します。例えば、10.5.21.R2.20231201。 既存の DB インスタンスは、次のメジャーまたはマイナーバージョンのアップグレードまで、10.5.21.R2 など、*major.minor.patch* を使用する場合があります。 |
| < 21 | 既存の DB インスタンスは、*major.minor.patch* を使用します。例えば、10.5.20.R2。 |
次の表に、RDS for MariaDB バージョン 10.4 の命名スキームを示します。
| 10.4 マイナーバージョン | 命名スキーム |
| --- | --- |
| ≥ 30 | 新しい DB インスタンスは、*major.minor.patch.YYMMDD* を使用します。例えば、10.4.30.R2.20231201。 既存の DB インスタンスは、次のメジャーまたはマイナーバージョンのアップグレードまで、10.4.30.R2 など、*major.minor.patch* を使用する場合があります。 |
| < 30 | 既存の DB インスタンスは、*major.minor.patch* を使用します。例えば、10.4.29.R2。 |
# RDS for MariaDB の RDS バージョン番号
RDS バージョン番号は `major.minor.patch` または `major.minor.patch.YYYYMMDD` 命名規則を使用します。RDS パッチバージョンには、リリース後にマイナーバージョンに追加された重要なバグ修正が含まれています。RDS 日付バージョン (*YYMMDD* ) はセキュリティパッチです。セキュリティパッチには、エンジンの動作を変更する可能性のある修正は含まれていません。
データベースの Amazon RDS バージョン番号を識別するには、まず次のコマンドを使用して `rds_tools` 拡張機能を作成する必要があります。
```
CREATE EXTENSION rds_tools;
```
RDS for MariaDB データベースの RDS バージョン番号は、次の SQL クエリで確認できます。
```
mysql> select mysql.rds_version();
```
例えば、RDS for MariaDB 10.6.14 データベースの RDS をクエリすると、次が出力が返されます。
```
+---------------------+
| mysql.rds_version() |
+---------------------+
| 10.6.14.R2.20231201 |
+---------------------+
1 row in set (0.01 sec)
```
# RDS for MariaDB のメジャーバージョンアップグレード
メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があります。そのため、Amazon RDS では、メジャーバージョンアップグレードは自動的に適用されません。DB インスタンスを手動で変更する必要があります。本稼働インスタンスへの適用前に、いずれのアップグレードも徹底的にテストすることをお勧めします。
**注記**
MariaDB 11.8 では、`require_secure_transport` のデフォルト値は `1` になり、安全な SSL/TLS 接続が必要です。非セキュア接続が必要な場合は、`0` に設定します。
Amazon RDS では、MariaDB データベースエンジンのメジャーバージョンに対して、以下のインプレースアップグレードをサポートしています。
+ MariaDB の任意バージョンから MariaDB 11.8 へ
+ MariaDB の任意バージョンから MariaDB 11.4 へ
+ MariaDB の任意バージョンから MariaDB 10.11 へ
+ MariaDB の任意バージョンから MariaDB 10.6 へ
+ MariaDB 10.4 から MariaDB 10.5 へ
カスタムパラメータグループを使用しており、メジャーバージョンアップグレードを実行する場合には、新しい DB エンジンバージョンのデフォルトのパラメータグループを指定するか、新しい DB エンジンバージョンの独自のカスタムパラメータグループを作成する必要があります。新しいパラメータグループを DB インスタンスと関連付けるには、アップグレードの完了後に、顧客主導型のデータベースの再起動が必要となります。パラメータグループの変更を適用するためにインスタンスを再起動する必要がある場合には、インスタンスのパラメータグループのステータスとして `pending-reboot` が表示されます。インスタンスのパラメータグループのステータスは、AWS マネジメントコンソール で表示するか、`describe-db-instances` などの「describe」呼び出しを実行して表示することができます。
## MariaDB DB インスタンスのアップグレード
MariaDB DB インスタンスの手動または自動アップグレードについては、「[DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)」を参照してください。
# RDS for MariaDB のマイナーバージョンの自動アップグレード
DB インスタンスの作成または変更時に次の設定を指定すると、DB インスタンスを自動的にアップグレードできます。
+ [**マイナーバージョンの自動アップグレード**] の設定は有効です。
+ **バックアップ保持期間**の設定は 0 より大きいです。
AWS マネジメントコンソールの場合、これらの設定は**AAdditional configuration** (追加設定) の下にあります。下図は、**Auto minor version upgrade** (自動マイナーバージョンアップグレード) 設定を示しています。
![\[マイナーバージョン自動アップグレードの設定\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/amvu.png)
これらの設定の詳細については、「[DB インスタンスの設定](USER_ModifyInstance.Settings.md)」をご参照ください。
一部の AWS リージョン の RDS for MariaDB メジャーバージョンでは、RDS によって 1 つのマイナーバージョンが自動アップグレードバージョンとして指定されます。Amazon RDS でマイナーバージョンのテストと承認が完了すると、メンテナンスウィンドウの間にマイナーバージョンアップグレードが自動的に行われます。RDS では、新しくリリースされたマイナーバージョンが自動アップグレードバージョンとして自動的に設定されることはありません。RDS によって新しい自動アップグレードバージョンが指定される前に、以下のような複数の基準が考慮されます。
+ 既知のセキュリティの問題
+ MariaDB コミュニティバージョンのバグ
+ マイナーバージョンがリリースされてからのフリート全体の安定性
**注記**
TLS バージョン 1.0 と 1.1 の使用のサポートは、MariaDB の特定のマイナーバージョン以降では終了しています。サポートしている MariaDB のマイナーバージョンの詳細については、「[Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS サポート](MariaDB.Concepts.SSLSupport.md)」参照してください。
次の AWS CLI コマンドを実行して、特定の AWS リージョン で指定された MariaDB マイナーバージョンの現在の自動マイナーアップグレードターゲットバージョンを確認できます。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version minor_version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version minor_version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
例えば、次の AWS CLI コマンドにより、米国東部 (オハイオ) AWS リージョン (us-east-2) の MariaDB マイナーバージョン 10.5.12 の自動マイナーアップグレードターゲットを特定できます。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version 10.5.16 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version 10.5.16 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
以下のような出力が生成されます。
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| True | 10.5.17 |
| False | 10.5.18 |
| False | 10.5.19 |
| False | 10.6.5 |
| False | 10.6.7 |
| False | 10.6.8 |
| False | 10.6.10 |
| False | 10.6.11 |
| False | 10.6.12 |
+--------------+-----------------+
```
この例では、`AutoUpgrade` 値は、MariaDB バージョン 10.5.17 の場合、`True` です。したがって、自動マイナーアップグレードターゲットは MariaDB バージョン 10.5.17 であり、出力で強調表示されています。
MariaDB DB インスタンスは、以下の基準を満たしている場合、メンテナンスウィンドウの間に自動的にアップグレードされます。
+ [**マイナーバージョンの自動アップグレード**] の設定は有効です。
+ **バックアップ保持期間**の設定は 0 より大きいです。
+ DB インスタンスでは、現在の自動アップグレードマイナーバージョン未満の DB エンジンのマイナーバージョンが実行されています。
詳細については、「[マイナーエンジンバージョンの自動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades)」を参照してください。
# RDS for MariaDB データベースをアップグレードするときにリードレプリカを使用してダウンタイムを短縮する
ほとんどの場合、MariaDB DB インスタンスをアップグレードする際のダウンタイムを減らすには、ブルー/グリーンデプロイが最適なオプションです。詳細については、「[データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する](blue-green-deployments.md)」を参照してください。
ブルー/グリーンデプロイを使用できず、MariaDB DB インスタンスが現在本稼働アプリケーションで使用されている場合は、次の手順を使用して DB インスタンスのデータベースバージョンをアップグレードできます。この手順により、アプリケーションの停止時間を短縮できます。
リードレプリカを使用して、ほとんどのメンテナンスステップを事前に実行し、実際の停止中に必要な変更を最小限に抑えることができます。この方法で、既存の DB インスタンスを変更せずに、新しい DB インスタンスのテストおよび準備ができます。
次の手順は、MariaDB バージョン 10.5 から MariaDB バージョン 10.6 へのアップグレードの例を示しています。他のメジャーバージョンへのアップグレードに、この同じ一般的なステップを使用できます。
**DB インスタンスの使用中に MariaDB データベースをアップグレードするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. MariaDB 10.5 DB インスタンスのリードレプリカを作成します。このプロセスにより、データベースのアップグレード可能なコピーが作成されます。DB インスタンスの他のリードレプリカも存在する場合があります。
1. コンソールで [**データベース**] を選択し、アップグレードする DB インスタンスを選択します。
1. [**アクション**] で [**リードレプリカの作成**] を選択します。
1. リードレプリカの **[DB instance identifier]** (DB インスタンス識別子) の値を指定し、**[DB instance class]** (DB インスタンスクラス) とその他の設定がご使用の MariaDB 10.5 DB インスタンスのものと一致していることを確認します。
1. [**Create read replica**] を選択します。
1. (オプション) リードレプリカが作成され、**ステータス**が [**利用可能**] になったら、リードレプリカをマルチ AZ 配置に変換し、バックアップを有効にします。
デフォルトでは、リードレプリカは、バックアップが無効なシングル AZ デプロイとして作成されます。リードレプリカは最終的に本番 DB インスタンスになるため、ベストプラクティスは、マルチ AZ デプロイを設定し、すぐにバックアップを有効にすることです。
1. コンソールで [**データベース**] を選択し、作成したばかりのリードレプリカを選択します。
1. **Modify** を選択します。
1. **マルチ AZ 配置**で、[**スタンバイインスタンスの作成**] を選択します。
1. **[Backup Retention Period]** (バックアップ保持期間) として、0 以外の正の値 (3 日など) を選択し、**[Continue]** (続行) を選択します。
1. [**変更のスケジューリング**] で、[**すぐに適用**] を選択します。
1. [**DB インスタンスの変更**] を選択します。
1. リードレプリカの **[Status]** (ステータス) が **[Available]** (使用可能) になったら、リードレプリカを MariaDB 10.6 にアップグレードします。
1. コンソールで [**データベース**] を選択し、作成したばかりのリードレプリカを選択します。
1. **Modify** を選択します。
1. **[DB engine version]** (DB エンジンバージョン) として、アップグレードする MariaDB 10.6 バージョンを選択し、**[Continue]** (続行) を選択します。
1. [**変更のスケジューリング**] で、[**すぐに適用**] を選択します。
1. [**Modify DB instance**] を選択してアップグレードをスタートします。
1. アップグレードが完了し、**[Status]** (ステータス) が **[Available]** (利用可能) になったら、アップグレードしたリードレプリカがソース MariaDB 10.5 DB インスタンスで最新であることを確認します。確認するには、リードレプリカに接続して、`SHOW REPLICA STATUS` コマンドを実行します。`Seconds_Behind_Master` フィールドが `0` である場合、レプリカは更新されています。
**注記**
MariaDB の旧バージョンは、`SHOW SLAVE STATUS` ではなく `SHOW REPLICA STATUS` を使用していました。10.6 より前の MariaDB バージョンを使用している場合は、`SHOW SLAVE STATUS` を使用します。
1. (オプション) リードレプリカのリードレプリカを作成します。
DB インスタンスをスタンドアロン DB インスタンスに昇格した後、リードレプリカを追加する場合、すぐにリードレプリカを作成できます。
1. コンソールで [**データベース**] を選択し、アップグレードしたばかりのリードレプリカを選択します。
1. [**アクション**] で [**リードレプリカの作成**] を選択します。
1. リードレプリカの **[DB instance identifier]** (DB インスタンス識別子) の値を指定し、**[DB instance class]** (DB インスタンスクラス) とその他の設定がご使用の MariaDB 10.5 DB インスタンスのものと一致していることを確認します。
1. [**Create read replica**] を選択します。
1. (オプション) リードレプリカのカスタム DB パラメータグループを設定します。
DB インスタンスをスタンドアロン DB インスタンスに昇格した後、カスタムパラメータグループを使用する場合、すぐにDB パラメータグループを作成して、リードレプリカに関連付けられます。
1. MariaDB 10.6 のカスタム DB パラメータグループを作成します。手順については、[Amazon RDS での DB パラメータグループの作成](USER_WorkingWithParamGroups.Creating.md) を参照してください。
1. 作成したばかりの DB パラメータグループで変更するパラメータを変更します。手順については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
1. コンソールで [**データベース**] を選択し、リードレプリカを選択します。
1. **Modify** を選択します。
1. **[DB parameter group]** (DB パラメータグループ) で、作成したばかりの MariaDB 10.6 DB パラメータグループを選択し、**[Continue]** (続行) を選択します。
1. [**変更のスケジューリング**] で、[**すぐに適用**] を選択します。
1. [**Modify DB instance**] を選択してアップグレードをスタートします。
1. MariaDB 10.6 リードレプリカをスタンドアロン DB インスタンスにします。
**重要**
MariaDB 10.6 のリードレプリカをスタンドアロン DB インスタンスに昇格すると、MariaDB 10.5 DB インスタンスのレプリカではなくなります。MariaDB 10.6 のリードレプリカの昇格は、ソースの MariaDB 10.5 DB インスタンスが読み取り専用モードであり、すべての書き込みオペレーションが停止されているメンテナンスウィンドウ中に行うことをお勧めします。昇格が完了したら、アップグレードした MariaDB 10.6 DB インスタンスに書き込み操作を送信して、書き込み操作が失われないようにできます。
また、MariaDB 10.6 のリードレプリカを昇格する前に、必要なすべてのデータ定義言語 (DDL) のオペレーションを MariaDB 10.6 のリードレプリカに対して実行することをお勧めします。例えば、インデックスの作成があります。これにより、昇格後の MariaDB 10.6 のリードレプリカのパフォーマンスへの悪影響を避けることができます。リードレプリカを昇格させるには、次の手順に従います。
1. コンソールで [**データベース**] を選択し、アップグレードしたばかりのリードレプリカを選択します。
1. [**アクション**] で、[**Promote (昇格)**] を選択します。
1. [**はい**] を選択して、リードレプリカインスタンスの自動バックアップを有効にします。詳細については、「[バックアップの概要](USER_WorkingWithAutomatedBackups.md)」を参照してください。
1. **[Continue]** (続行) をクリックします。
1. [**Promote Read Replica**] を選択します。
1. これで、MariaDB データベースのアップグレードバージョンが作成されました。この時点で、アプリケーションを新しい MariaDB 10.6 DB インスタンスに送信できます。
# イベントによる RDS for MariaDB DB エンジンのアップグレードのモニタリング
RDS for MariaDB データベースのエンジンバージョンをアップグレードすると、Amazon RDS はプロセスの各フェーズで特定のイベントを発行します。アップグレードの進行状況を追跡するには、これらのイベントを表示またはサブスクライブします。
RDS イベントの詳細については、「[Amazon RDS イベントのモニタリング](working-with-events.md)」を参照してください。
エンジンのアップグレード中に発生する特定の Amazon RDS イベントの詳細については、「[ Amazon RDS イベントカテゴリとイベントメッセージ](USER_Events.Messages.md)」を参照してください。
# MariaDB DB スナップショットエンジンバージョンのアップグレード
Amazon RDS を使用すると、MariaDB DB インスタンスのストレージボリュームの DB スナップショットを作成できます。DB スナップショットを作成するとき、スナップショットは DB インスタンスが使用するエンジンバージョンに基づきます。DB スナップショットのエンジンバージョンをアップグレードできます。
RDS for MariaDB では、使用可能なすべてのエンジンバージョンにアップグレードできます。暗号化されている DB スナップショットまたは暗号化されていない DB スナップショットをアップグレードできます。
RDS for MariaDB DB スナップショットで使用可能なエンジンバージョンを表示するには、次の AWS CLI 例を使用します。
```
aws rds describe-db-engine-versions --engine mariadb --include-all --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
スナップショットの結果が表示されない場合は、エンジンのバージョンが非推奨である可能性があります。エンジンのバージョンが非推奨の場合は、最新のメジャーバージョンのアップグレードターゲットにアップグレードするか、そのバージョンで利用可能な他のアップグレードターゲットにアップグレードすることをお勧めします。詳細については、「[RDS for MariaDB でサポートされていないエンジンバージョンの DB スナップショットのアップグレードオプション](mariadb-upgrade-snapshot.upgrade-options.md)」を参照してください。
新しいエンジンバージョンにアップグレードした DB スナップショットをリストアしたら、アップグレードに問題がないか必ずテストしてください。主なバージョンアップグレードの詳細は、[MariaDB DB エンジンのアップグレード](USER_UpgradeDBInstance.MariaDB.md) を参照してください。DB スナップショットをリストアする方法については [DB インスタンスへの復元](USER_RestoreFromSnapshot.md) をご覧ください。
**注記**
自動バックアッププロセス中に作成された自動 DB スナップショットをアップグレードすることはできません。
AWS マネジメントコンソール、AWS CLI、または RDS API を使用して DB スナップショットをアップグレードできます。
------
#### [ Console ]
AWS マネジメントコンソールを使用して DB スナップショットエンジンのバージョンをアップグレードするには、次の手順を使用します。
**DB スナップショットをアップグレードするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、「**Snapshots**」 を選択します。
1. アップグレードしたいスナップショットを選択します。
1. [**アクション**] は、[**スナップショットのアップグレード**] を選択します。[**スナップショットのアップグレード**] ページが表示されます。
1. アップグレードする [**新しいエンジンバージョン**] を選択します。
1. [**変更を保存**] を選択してスナップショットをアップグレードします。
アップグレード中は、この DB スナップショットに関するスナップショット操作が、すべて無効になります。また、DB スナップショットのステータスは、**利用可能**から**アップグレード中**に変わり、プロセスが完了すると**アクティブ**に変わります。スナップショットの破損問題で DB スナップショットをアップグレードできない場合、ステータスは**使用不可**になります。この状態からスナップショットを復元することはできません。
**注記**
DB スナップショットアップグレードが失敗した場合、スナップショットは元の状態にロールバックします。
------
#### [ AWS CLI ]
DB スナップショットを新しいバージョンのデータベースエンジンにアップグレードするには、AWS CLI の [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html) コマンドを実行します。
**オプション**
+ `--db-snapshot-identifier` – アップグレードする DB スナップショットの識別子です。識別子は独自の Amazon リソースネーム (ARN) にしてください。詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
+ `--engine-version` – DB スナップショットをこのエンジンバージョンにアップグレードする。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds modify-db-snapshot \
2.
3. --db-snapshot-identifier my_db_snapshot \
4. --engine-version new_version
```
Windows の場合:
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
------
#### [ Amazon RDS API ]
DB スナップショットを新しいデータベースエンジンバージョンにアップグレードするには、RDS API の [ModifyDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) オペレーションを呼び出します。
**パラメータ**
+ `DBSnapshotIdentifier` – アップグレードする DB スナップショットの識別子です。識別子は独自の Amazon リソースネーム (ARN) にしてください。詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
+ `EngineVersion` – DB スナップショットをこのエンジンバージョンにアップグレードする。
------
# RDS for MariaDB でサポートされていないエンジンバージョンの DB スナップショットのアップグレードオプション
次の表は、RDS for MariaDB DB スナップショットでサポートされていないエンジンバージョンからアップグレードできるエンジンバージョンを示しています。
**注記**
選択したエンジンバージョンにアップグレードするには、DB スナップショットを複数回アップグレードする必要がある場合があります。
| DB スナップショットエンジンのバージョン | アップグレード可能なエンジンバージョン |
| --- | --- |
| 10.0.17、10.0.24、10.0.28、10.0.31、10.0.32、10.0.34、10.0.35 | 10.0.38、10.1.48、10.6.19、10.6.20、10.11.9、10.11.10、11.4.3、11.4.4、11.8.3 |
| 10.1.14、10.1.16、10.1.19、10.1.23、10.1.26、10.1.31、10.1.34 | 10.1.48、10.2.44、10.6.19、10.6.20、10.11.9、10.11.10、11.4.3、11.4.4、11.8.3 |
| 10.2.11、10.2.12、10.2.15、10.2.21、10.2.32、10.2.37、10.2.39、10.2.40、10.2.41、10.2.43 | 10.2.44、10.3.39、10.6.19、10.6.20、10.6.21、10.11.9、10.11.10、10.11.11、11.4.3、11.4.4、11.8.3 |
| 10.3.8、10.3.13、10.3.20、10.3.23、10.3.28、10.3.31、10.3.32 | 10.3.39、10.4.34、10.6.19、10.6.20、10.6.21、10.11.9、10.11.10、10.11.11、11.4.3、11.4.4、11.8.3 |
| 10.4.8 | 10.4.34、10.5.16、10.5.17、10.5.18、10.5.20、10.5.21、10.5.22、10.5.23、10.5.24、10.5.25、10.5.26、10.5.27、10.5.28、10.6.8、10.6.10、10.6.11、10.6.13、10.6.14、10.6.15、10.6.16、10.6.18、10.6.19、10.6.20、10.6.21、10.11.4、10.6.17、10.11.5、10.11.6、10.11.7、10.11.8、10.11.9、10.11.10、10.11.11 |
# Amazon RDS for MariaDB DB インスタンスへのデータのインポート
さまざまな手法を使用して、RDS for MariaDB DB インスタンスにデータをインポートできます。最善のアプローチは、いくつかの要因によって異なります。
+ データのソース
+ データ量
+ 1 回限りのインポートか継続的なインポートか
+ ダウンタイムの長さ
データと同時にアプリケーションも移行する場合は、ダウンタイムの長さを考慮することが重要です。
次の表は、RDS for MariaDB DB インスタンスにデータをインポートする手法の一覧です。
**注記**
Amazon RDS は、Amazon S3 for MariaDB の `mariadb-backup` またはインポートをサポートしていません。
| ソース | データ量 | 1 回または進行中 | アプリケーションのダウンタイム | 手法 | 詳細情報 |
| --- | --- | --- | --- | --- | --- |
| オンプレミスまたは Amazon EC2 の既存の MariaDB データベース | いずれか | 継続的 | Minimal | レプリケーション元として既存の MariaDB データベースを使用してレプリケーションを設定します。 MariaDB DB インスタンスへのレプリケーションを設定するには、外部インスタンスが MariaDB バージョン 10.0.24 以降の場合は MariaDB グローバルトランザクション識別子 (GTID) を使用し、10.0.24 より前のバージョンでは MariaDB インスタンスのバイナリログ座標を使用できます。MariaDB GTID の実装方法は、Amazon RDS ではサポートされていない MySQL GTID とは異なります。 | [外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定](MySQL.Procedural.Importing.External.ReplMariaDB.md) [ダウンタイムを短縮して Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-reduced-downtime.md) |
| 既存のデータベース | すべて | 1 回または進行中 | 最小限 | AWS Database Migration Service を使用してダウンタイムを最小限にしてデータベースを移行し、多くのデータベース DB エンジンで継続的なレプリケーションを継続します。 | 「*AWS Database Migration Service ユーザーガイド*」の「[AWS Database Migration Service とは?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」および「[MySQL 互換データベースの AWS DMS のターゲットとしての使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html)」 |
| 既存の MariaDB DB インスタンス | いずれか | 1 回または進行中 | 最小限 | 継続的なレプリケーション用のリードレプリカを作成します。新しい DB インスタンスの 1 回限りの作成用のリードレプリカを昇格させます。 | [DB インスタンスのリードレプリカの操作](USER_ReadRepl.md) |
| 既存の MariaDB データベース | スモール | 1 回 | ある程度 | コマンドラインユーティリティを使用して、MariaDB DB インスタンスに直接データをコピーします。 | [外部の MariaDB データベースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-external-database.md) |
| 既存のデータベースに保存されないデータ | ミディアム | 1 回 | ある程度 | フラットファイルを作成し、MariaDB の `LOAD DATA LOCAL INFILE` ステートメントを使用してインポートします。 | [任意のソースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-any-source.md) |
**注記**
`mysql` システムデータベースには、DB インスタンスへのログインとデータへのアクセスに必要な認証と認可の情報が含まれています。DB インスタンスにある `mysql` データベースのテーブル、データ、その他のコンテンツを削除、変更、名前変更、または切り捨てを行うとエラーが発生し、DB インスタンスやデータにアクセスできなくなる場合があります。この場合は、AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) コマンドを使用して、スナップショットから DB インスタンスを復元できます。DB インスタンスは、[https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) コマンドを使用して復元できます。
# MariaDB のデータインポートに関する考慮事項
以下のコンテンツには、MariaDB へのデータのロードに関連する技術情報が含まれています。このコンテンツは、MariaDB サーバーアーキテクチャに精通しているユーザーを対象としています。
## バイナリログ記録
バイナリログ記録を有効にすると、データロードのパフォーマンスが低下し、ログを無効にした場合と比較して最大 4 倍の追加のディスク領域が必要になります。データのロードに使用されるトランザクションサイズは、システムのパフォーマンスとディスク容量のニーズに直接影響します。トランザクションが大きいほど、より多くのリソースが必要になります。
## トランザクションサイズ
トランザクションサイズは、MariaDB データロードの以下の側面に影響します。
+ リソース消費
+ ディスクスペースの使用率
+ プロセスの再開
+ 復旧時間
+ 入力形式 (フラットファイルまたは SQL)
このセクションでは、トランザクションサイズがバイナリログ作成に与える影響について説明し、大量のデータロード中にバイナリログ作成を無効にするケースを作成します。Amazon RDS 自動バックアップ保持期間を設定することで、バイナリログ作成を有効または無効にすることができます。値が 0 以外の場合はバイナリログ作成が有効になり、0 の場合は無効になります。詳細については、「[バックアップの保存期間](USER_WorkingWithAutomatedBackups.BackupRetention.md)」を参照してください。
このセクションでは、大規模なトランザクションが InnoDB に与える影響と、トランザクションサイズを小さく保つことが重要な理由についても説明します。
### 小さいトランザクション
トランザクションが小さい場合、バイナリログ作成により、データのロードに必要なディスク書き込み数が 2 倍になります。この影響は、他のデータベースセッションのパフォーマンスを著しく低下させ、データのロードに必要な時間を長くします。劣化の程度は、以下の要因に一部依存します。
+ アップロードレート
+ ロード中に発生するその他のデータベースアクティビティ
+ Amazon RDS DB インスタンスの容量
バイナリログは、バックアップおよび削除されるまでにロードされたデータの量とほぼ同じディスク容量を消費します。Amazon RDS は、バイナリログを頻繁にバックアップして削除することで、この容量を最小限に抑えます。
### 大きいトランザクション
大規模なトランザクションの場合、バイナリログによって、次の理由により IOPS とディスク使用量が 3 倍になります。
+ バイナリログキャッシュは、トランザクションデータを一時的にディスクに保存します。
+ このキャッシュはトランザクションのサイズに応じて大きくなり、ディスク領域を消費します。
+ トランザクション (コミットまたはロールバック) が完了すると、システムはキャッシュをバイナリログにコピーします。
このプロセスでは、データのコピーが 3 つ作成されます。
+ 元のデータ
+ ディスク上のキャッシュ
+ 最後のバイナリログエントリ
書き込みオペレーションごとに追加の IO が発生し、パフォーマンスにさらに影響を及ぼします。
このため、バイナリログ記録には、ログ記録を無効にした場合と比較して 3 倍のディスク容量が必要です。例えば、1 つのトランザクションとして 10 GiB のデータをロードすると、次の 3 つのコピーが作成されます。
+ テーブルデータに 10 GiB
+ バイナリログキャッシュに 10 GiB
+ バイナリログファイルに 10 GiB
必要な一時ディスク容量の合計は 30 GiB です。
ディスク容量に関する重要な考慮事項:
+ キャッシュファイルは、セッションが終了するか、新しいトランザクションによって別のキャッシュが作成されるまで保持されます。
+ バイナリログはバックアップされるまで保持され、長期間にわたって 20 GiB (キャッシュとログ) が保持される可能性があります。
`LOAD DATA LOCAL INFILE` を使用してデータをロードする場合、ロード前に行われたバックアップからデータベースを復元する必要がある場合に備えて、データ復旧によって 4 番目のコピーが作成されます。復旧時に、MariaDB はバイナリログからフラットファイルにデータを抽出します。その後 MariaDB は `LOAD DATA LOCAL INFILE` を実行します。上記の例の場合、この復旧には合計 40 GiB、つまりテーブル、キャッシュ、ログ、ローカルファイルごとに 10 GiB の一時ディスク領域が必要です。少なくとも 40 GiB の空きディスク容量がないと、復旧は失敗します。
### 大規模なデータロードの最適化
大量のデータをロードする場合は、バイナリログを無効にして、オーバーヘッドとディスク領域の要件を削減します。バイナリログ記録を無効にするには、バックアップ保持期間を 0 に設定します。ロードが完了したら、バックアップ保持期間を適切なゼロ以外の値に復元します。詳細については、設定テーブルの「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」および「[バックアップ保持期間](USER_ModifyInstance.Settings.md)」を参照してください。
**注記**
DB インスタンスがリードレプリカのソース DB インスタンスである場合、バックアップ保持期間を 0 に設定することはできません。
データをロードする前に、DB スナップショットを作成することをお勧めします。詳細については、「[手動バックアップの管理](USER_ManagingManualBackups.md)」を参照してください。
## InnoDB
undo ログと復旧のオプションに関する以下の情報は、InnoDB トランザクションを小さくしてデータベースのパフォーマンスを最適化することをサポートしています。
### InnoDB の undo ログについて
undo ログは、トランザクションのロールバックを有効にし、マルチバージョン同時実行制御 (MVCC) をサポートするログ記録メカニズムです。
MariaDB 10.11 以前のバージョンでは、undo ログは InnoDB システムテーブルスペース (通常は ibdata1) に保存され、パージスレッドによって削除されるまで保持されます。その結果、大規模なデータロードトランザクションによってシステムテーブルスペースが非常に大きくなり、データベースを再作成しない限り再利用できないディスク領域が消費される可能性があります。
すべての MariaDB バージョンでは、最も古いアクティブなトランザクションがコミットまたはロールバックされるまで、パージスレッドは undo ログの削除を待機する必要があります。データベースが、ロード中に他のトランザクションを処理する場合、そのトランザクションがコミットされ、他のトランザクションが MVCC の undo ログを必要としない場合でも、それらの undo ログも蓄積され、削除できません。この場合、読み取り専用トランザクションを含むすべてのトランザクションが遅くなります。このスローダウンは、すべてのトランザクションが、ロードトランザクションだけでなく、任意のトランザクションが変更するすべての行にアクセスするために発生します。実際には、トランザクションは、長時間実行されるロードトランザクションによって undo ログのクリーンアップ中に消去されなかった undo ログをスキャンする必要があります。これは、変更された行にアクセスするオペレーションのパフォーマンスに影響します。
### InnoDB トランザクション復旧オプション
InnoDB はコミットオペレーションを最適化しますが、大規模なトランザクションのロールバックは遅くなります。復旧を高速化するには、ポイントインタイムリカバリを実行するか、DB スナップショットを復元します。詳細については、「[ポイントインタイムリカバリ](USER_PIT.md)」および「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
## データインポート形式
MariaDB は、フラットファイルと SQL の 2 つのデータインポート形式をサポートしています。各形式に関する情報を確認して、ニーズに最適なオプションを決定します。
### フラットファイル
小規模なトランザクションの場合は、`LOAD DATA LOCAL INFILE` を使用してフラットファイルをロードします。このデータインポート形式は、SQL を使用する場合に比べて次のようなメリットがあります。
+ ネットワークトラフィックの削減
+ データ転送コストの削減
+ データベース処理オーバーヘッドの減少
+ より高速な処理
`LOAD DATA LOCAL INFILE` はフラットファイル全体を 1 つのトランザクションとしてロードします。個々のファイルのサイズを小さく保つと、次の利点があります。
+ **再開機能** - どのファイルがロードされたかを追跡できます。ロード中に問題が発生した場合、中断したところから再開できます。一部のデータを Amazon RDS に再送信する必要がある場合でも、ファイルが小さいと、再送信される量は最小限ですみます。
+ **同時データロード** – 単一ファイルのロードに十分な IOPS とネットワーク帯域幅がある場合、同時にロードすれば時間を節約できます。
+ **ロード速度制御** – データロードが他のプロセスに悪影響を及ぼす場合は、ファイル間の間隔を増やすことでロード速度を制御できます。
大規模なトランザクションでは、`LOAD DATA LOCAL INFILE` を使用してデータをインポートするメリットが減ります。大量のデータを小さなファイルに分割できない場合は、SQL の使用を検討してください。
### SQL
SQL にはフラットファイルに比べて、トランザクションサイズを簡単に小さく保つことができるという大きなメリットがあります。ただし、SQL のロードにはフラットファイルよりもかなり時間がかかる場合があります。また、障害が発生した後、どこから再開するかを判断するのが難しい場合があります。mariadb-dump ファイルを再開することはできません。mariadb-dump ファイルのロード中にエラーが発生した場合、ロードを再開するにはファイルを変更するか置き換える必要があります。または、障害の原因を修正した後、ロード前の時点に復元してファイルを再開する必要があります。詳細については、「[ポイントインタイムリカバリ](USER_PIT.md)」を参照してください。
## データベースチェックポイントに Amazon RDS DB スナップショットを使用する
バイナリログ記録を使用せずに、数時間または数日など長期間にわたってデータをロードする場合は、DB スナップショットを使用して、データの安全性を確保するために定期的なチェックポイントを提供します。各 DB スナップショットは、システム障害やデータ破損イベント時の復旧ポイントとして機能するデータベースインスタンスの一貫したコピーを作成します。DB スナップショットは高速であるため、頻繁なチェックポイント作成によるロードパフォーマンスへの影響は最小限に抑えられます。データベースの耐久性や復旧機能に影響を与えることなく、以前の DB スナップショットを削除できます。DB スナップショットの詳細については、「[手動バックアップの管理](USER_ManagingManualBackups.md)」を参照してください。
## データベースのロード時間を短縮する
以下の項目は、ロード時間を短縮するための追加のヒントです。
+ MariaDB データベースにデータをロードする前に、すべてのセカンダリインデックスを作成します。他のデータベースシステムとは異なり、MariaDB はセカンダリインデックスを追加または変更するときにテーブル全体を再構築します。このプロセスでは、インデックスが変更された新しいテーブルが作成され、すべてのデータがコピーされ、元のテーブルが削除されます。
+ プライマリキーの順序でデータをロードします。InnoDB テーブルの場合、これによりロード時間が 75%～80% 短縮され、データファイルサイズが 50% 短縮されます。
+ `foreign_key_checks` を `0` に設定して、外部キーの制約を無効にします。これは多くの場合、`LOAD DATA LOCAL INFILE` を使用してロードされたフラットファイルで必要となります。どのロードでも、外部キーチェックを無効にすると、データのロードが高速化されます。ロードが完了したら、`foreign_key_checks` を `1` に設定して制約を再度有効にし、データを検証します。
+ リソース制限に近づかない限り、データを同時にロードします。複数のテーブルセグメント間で同時ロードを有効にするには、必要に応じてパーティションテーブルを使用します。
+ SQL 実行のオーバーヘッドを減らすには、複数の `INSERT` ステートメントを単一の複数値 `INSERT` オペレーションに結合します。`mariadb-dump` は、この最適化を自動的に実装します。
+ `innodb_flush_log_at_trx_commit` を `0` に設定することで、InnoDB ログ IO オペレーションを減らします。ロードが完了したら、`innodb_flush_log_at_trx_commit` を `1` に戻します。
**警告**
`innodb_flush_log_at_trx_commit` を `0` に設定すると、InnoDB はコミットごとではなく毎秒ログをフラッシュします。この設定はパフォーマンスを向上させますが、システム障害時にトランザクションが失われるリスクがあります。
+ リードレプリカがない DB インスタンスにデータをロードする場合は、`sync_binlog` を `0` に設定します。ロードが完了したら、`sync_binlog parameter` を `1` に戻します。
+ DB インスタンスをマルチ AZ 配置に変換する前に、シングル AZ DB インスタンスにデータをロードします。DB インスタンスが既にマルチ AZ 配置を使用している場合は、データロードのためにシングル AZ 配置に切り替えることはお勧めしません。これで実現できる改善はわずかだけです。
# 外部の MariaDB データベースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする
既存の MariaDB データベースから RDS for MariaDB DB インスタンスに、データをインポートできます。これを行うには、[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) または [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) を使用してデータベースをコピーし、データベースを RDS for MariaDB DB インスタンスに直接パイプ処理します。`mysqldump` または `mariadb-dump` コマンドラインユーティリティは、データのバックアップや、MariaDB サーバーから別の場所への転送によく使用されます。このユーティリティは、MariaDB クライアントソフトウェアに含まれています。
MariaDB 11.0.1 以降では、`mariadb-dump` を `mysqldump` の代わりに使用する必要があります。
外部のデータベースから Amazon RDS DB インスタンスにデータを移動するための一般的な `mysqldump` コマンドは、次の例のようになります。値を自分の情報に置き換えます。MariaDB 11.0.1 以降のバージョンでは、`mysqldump` を `mariadb-dump` に置き換えます。
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**重要**
`-p` オプションと入力するパスワードの間にスペースを残していないことを確認します。
セキュリティのベストプラクティスとして、この例に表示されているプロンプト以外の認証情報を指定してください。
次の推奨事項と考慮事項に注意してください。
+ ダンプファイルから次のスキーマを除外します。
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` および `mariadb-dump` ユーティリティは、これらのスキーマをデフォルトで除外します。
+ ユーザーや権限を移行する必要がある場合は、再作成するデータ制御言語 (DCL) を生成するツールの使用を検討します。例えば、[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) ユーティリティがあります。
+ インポートを実行するには、そのユーザーに DB インスタンスへのアクセスが許可されていることを確認してください。詳細については、「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。
使用するパラメータは次のとおりです。
+ `-u local_user` - ユーザー名を指定します。このパラメータの初回の使用では、`--databases` パラメータによって識別されたローカル MariaDB データベースのユーザーアカウントの名前を指定します。
+ `--databases database_name` — Amazon RDS にインポートするローカル MariaDB インスタンスのデータベースの名前を指定します。
+ `--single-transaction` - ローカルデータベースからロードされたすべてのデータが、ある時点において一貫していることを確認します。`mysqldump` または `mariadb-dump` によるデータの読み取り中に他のプロセスがデータを変更する場合は、このパラメータを使用することでデータの整合性を維持できます。
+ `--compress` - ローカルデータベースからのデータを、Amazon RDS に送信する前に圧縮することで、ネットワーク帯域幅の消費量を削減します。
+ `--order-by-primary` - 各テーブルのデータをプライマリキーでソートすることで、ロード時間を短縮します。
+ `--routines` − ストアドプロシージャや関数などのルーチンが、コピーするデータベースに存在する場合に使用します。パラメータを `0` に設定し、インポートプロセス中にルーチンを除外します。その後、Amazon RDS データベースでルーチンを手動で再作成します。
+ `--triggers` − コピーするデータベースにトリガーが存在する場合に使用します。パラメータを `0` に設定し、インポートプロセス中にトリガーを除外します。その後、Amazon RDS データベースでトリガーを手動で再作成します。
+ `--events` − コピーするデータベースにイベントが存在する場合に使用します。パラメータを `0` に設定し、インポートプロセス中にイベントを除外します。その後、Amazon RDS データベースでイベントを手動で再作成します。
+ `-plocal_password` - パスワードを指定します。このパラメータの初回の使用では、初期の `-u` パラメータにより識別されるユーザーアカウントのパスワードを指定します。
+ `-u RDS_user` - ユーザー名を指定します。このパラメータの 2 回目の使用では、`--host` パラメータによって識別された MariaDB DB インスタンスのデフォルトデータベースのユーザーアカウントの名前を指定します。
+ `--port port_number` — MariaDB DB インスタンスのポートを指定します。DB インスタンスの作成時に値を変更していない限り、デフォルトでは 3306 です。
+ `--host host_name` — Amazon RDS DB インスタンスのエンドポイント、例えば からのドメインネームシステム (DNS) 名を指定します。`myinstance.123456789012.us-east-1.rds.amazonaws.com`エンドポイントの値は、Amazon RDS コンソールの DB インスタンスの詳細で確認できます。
+ `-pRDS_password` - パスワードを指定します。このパラメータの 2 回目の使用では、2 回目の `-u` パラメータにより識別されるユーザーアカウントのパスワードを指定します。
Amazon RDS データベースで、ストアドプロシージャ、トリガー、関数、イベントを必ず手動で作成してください。これらのオブジェクトのいずれかがコピー対象のデータベースに含まれている場合は、`mysqldump` または `mariadb-dump` の実行時に除外します。これを行うには、`mysqldump` または `mariadb-dump` コマンドに次のパラメータを含めます。
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**例**
次の例では、ローカルホストにある `world` サンプルデータベースを、RDS for MariaDB DB インスタンスにコピーします。値を自分の情報に置き換えます。
Linux、macOS、Unix の場合:
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Windows の場合:
Windows プログラムメニューの **[コマンドプロンプト]** を右クリックし、**[管理者として実行]** を選択して開いたコマンドプロンプトで次のコマンドを実行します。値を自分の情報に置き換えます。
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**注記**
セキュリティのベストプラクティスとして、例に表示されているプロンプト以外の認証情報を指定します。
# ダウンタイムを短縮して Amazon RDS for MariaDB DB インスタンスにデータをインポートする
場合によっては、ライブアプリケーションをサポートする外部 MariaDB データベースから RDS for MariaDB DB インスタンスにデータをインポートする必要がある場合があります。次の手順を使用して、アプリケーションの可用性への影響を最小限に抑えることができます。この手順は、巨大なデータベースを使用する場合にも役立ちます。この手順を使用すると、ネットワーク経由で AWS に渡されるデータ量を削減することで、インポートのコストを削減できます。
この手順では、データベースデータのコピーを Amazon EC2 インスタンスに送信し、そのデータを新しい Amazon RDS データベースにインポートします。次に、レプリケーションを使用して、Amazon RDS データベースをライブ外部インスタンスで最新の状態にした後、アプリケーションを Amazon RDS データベースにリダイレクトします。外部のインスタンスが MariaDB 10.0.24 以降であり、ターゲットインスタンスが RDS for MariaDB である場合は、グローバルトランザクション識別子 (GTID) に基づいて MariaDB のレプリケーションを設定します。それ以外の場合は、バイナリログの調整に基づいてレプリケーションを設定します。外部データベースがサポートしている場合は、GTID ベースのレプリケーションが推奨されます。GTID ベースのレプリケーションは信頼性の高い方法だからです。詳細については、MariaDB ドキュメントの「[グローバルトランザクション ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/)」を参照してください。
次の図は、外部 MariaDB データベースを Amazon RDS 上の MariaDB データベースにインポートする様子を示しています。
![\[外部 MariaDB データベースを Amazon RDS 上の MariaDB データベースにインポートするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_1.png)
## タスク 1: 既存のデータベースのコピーを作成する
最小限のダウンタイムで RDS for MariaDB データベースに大量のデータを移行するプロセスでは、最初のステップとしてソースデータのコピーを作成します。
次の図は、MariaDB データベースのバックアップの作成を示しています。
![\[MariaDB データベースのバックアップを作成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
SQL 形式または区切り文字付きテキスト形式でデータベースのバックアップを作成するには、`mysqldump` または `mariadb-dump` ユーティリティを使用できます。MariaDB 10.5 では、クライアントは [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) と呼ばれます。MariaDB 11.0.1 以降では、`mariadb-dump` を `mysqldump` の代わりに使用する必要があります。非運用環境で各形式のテスト実行を行って、どちらの方法が `mysqldump` または `mariadb-dump` の実行時間が短いか確認することをお勧めします。
また、ロードに区切り文字付きテキスト形式を使用することでもたらされるメリットに対して、`mysqldump` または `mariadb-dump` のパフォーマンスの重み付けをすることをお勧めします。区切り文字付きテキスト形式を使用したバックアップでは、ダンプされる各テーブルについてタブ区切りテキストファイルを作成されます。データベースのインポートに必要な時間を短縮するため、`LOAD DATA LOCAL INFILE` コマンドを使用してこれらのファイルを同時にロードできます。詳細については、任意のソースからデータをインポートする手順の「[ステップ 5: データをロードする](mariadb-importing-data-any-source.md#mariadb-importing-data-any-source-load-data)」を参照してください。
バックアップ操作をスタートする前に、Amazon RDS にコピーする MariaDB データベースでレプリケーションのオプションを設定してください。レプリケーションのオプションには、バイナリログ記録の有効化や一意のサーバー ID の設定が含まれます。これらのオプションを設定すると、サーバーはデータベーストランザクションのログ作成をスタートし、このプロセスの後でこのサーバーをソースレプリケーションインスタンスにするために準備します。
次の推奨事項と考慮事項に注意してください。
+ `--single-transaction` オプションは、データベースの一貫した状態をダンプするため、`mysqldump` または `mariadb-dump` と共に使用します。有効なダンプファイルを確保するために、`mysqldump` または `mariadb-dump` の実行中はデータ定義言語 (DDL) ステートメントを実行しないでください。これらのオペレーションに対してメンテナンスウィンドウをスケジュールできます。
+ ダンプファイルから次のスキーマを除外します。
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` および `mariadb-dump` ユーティリティは、これらのスキーマをデフォルトで除外します。
+ ユーザーや権限を移行する必要がある場合は、再作成するデータ制御言語 (DCL) を生成するツールの使用を検討します。例えば、[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) ユーティリティがあります。
### レプリケーションオプションを設定するには
1. `my.cnf` ファイルを編集します。このファイルは `/etc` にあります。
```
sudo vi /etc/my.cnf
```
`log_bin` オプションと `server_id` オプションを `[mysqld]` に追加します。`log_bin` オプションは、バイナリログファイルのファイル名識別子を提供します。`server_id` オプションは、ソースとレプリカの関係のサーバーに一意の識別子を提供します。
次の例は、`my.cnf` ファイルの更新された `[mariadb]` セクションを示しています。
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
詳細については、MariaDB ドキュメントの「[Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication)」を参照してください。
1. マルチ AZ DB クラスターでのレプリケーションでは、`gtid_strict_mode` を有効にします。詳細については、MariaDB のドキュメントの「[gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode)」を参照してください。
DB インスタンスでのレプリケーションには、`gtid_strict_mode` を有効にする必要はありません。
1. `mariadb` サービスを再起動します。
```
sudo service mariadb restart
```
### 既存のデータベースのバックアップコピーを作成するには
1. `mysqldump` または `mariadb-dump` ユーティリティを使用し、SQL 形式または区切り文字付きテキスト形式を指定して、データのバックアップを作成します。
パフォーマンスを向上させ、データ整合性を確保するために、`mysqldump` または `mariadb-dump` で `--order-by-primary` オプションと `--single-transaction` オプションを使用します。
MySQL システムデータベースをバックアップに含めないためには、`mysqldump` または `mariadb-dump` で `--all-databases` オプションを使用しないでください。詳細については、MySQL ドキュメントの「[Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html)」を参照してください。
バックアップファイルが作成されるディレクトリを書き込み可能にするために、必要に応じて `chmod` を使用します。
**重要**
Windows で、管理者としてコマンドウィンドウを実行します。
+ SQL 出力を作成するには、次のコマンドを使用します。MariaDB 10.11 以前のバージョンでは、`mariadb-dump` を `mysqldump` に置き換えます。
Linux、macOS、Unix の場合:
```
sudo mariadb-dump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定します。
Windows の場合:
```
mariadb-dump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定します。
+ 区切り文字付きテキスト出力を作成するには、次のコマンドを使用します。MariaDB 11.01 以降のバージョンでは、`mysqldump` を `mariadb-dump` に置き換えます。
Linux、macOS、Unix の場合:
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Windows の場合:
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定します。
Amazon RDS データベースで、ストアドプロシージャ、トリガー、関数、イベントを必ず手動で作成してください。これらのオブジェクトのいずれかがコピー対象のデータベースに含まれている場合は、`mysqldump` または `mariadb-dump` の実行時に除外します。これを行うには、`mysqldump` または `mariadb-dump` コマンドで以下の引数を含めます。
`--routines=0`
`--triggers=0`
`--events=0`
`mysqldump` を実行して区切り文字付きテキスト形式を指定すると、`CHANGE MASTER TO` コメントが返されます。このコメントには、マスターログのファイル名と場所が含まれます。外部インスタンスが MariaDB 10.0.23 以前のバージョンの場合は、`MASTER_LOG_FILE` および `MASTER_LOG_POS` の値を書き留めてください。これらの値は、レプリケーションを設定するときに必要です。
MariaDB バージョンでは、次の出力が返されます。
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. 使用している外部インスタンスが MariaDB バージョン 10.0.24 以降である場合は、GTID ベースのレプリケーションを使用します。外部 MariaDB インスタンスで `SHOW MASTER STATUS` を実行してバイナリログファイル名と場所を取得し、外部 MariaDB インスタンス上で `BINLOG_GTID_POS` を実行してそれらを GTID に変換します。
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
返された GTID を書き留めます。これはレプリケーションを設定する際に必要となります。
1. Amazon RDS データベースにデータをコピーするために必要なネットワークリソースの量を減らすために、コピーされたデータを圧縮します。バックアップファイルのサイズをメモします。この情報は、作成する Amazon EC2 インスタンスの大きさを決定するときに必要です。作業が終了したら、GZIP または任意の圧縮ユーティリティを使用してバックアップファイルを圧縮します。
+ SQL 出力を圧縮するには、次のコマンドを使用します。
```
gzip backup.sql
```
+ 区切り文字付きテキスト出力を圧縮するには、次のコマンドを使用します。
```
tar -zcvf backup.tar.gz target_directory
```
## タスク 2: Amazon EC2 インスタンスを作成し、圧縮したデータベースをコピーする
圧縮したデータベースのバックアップファイルを Amazon EC2 インスタンスにコピーする場合、データベースインスタンス間で非圧縮データを直接コピーするよりも必要なネットワークリソースは少なくなります。データを Amazon EC2 にコピーしたら、そこから MariaDB データベースに直接コピーできます。ネットワークリソースのコストを節約するには、Amazon EC2 インスタンスが Amazon RDS DB インスタンスと同じ AWS リージョンに存在している必要があります。Amazon EC2 インスタンスを Amazon RDS データベースと同じ AWS リージョンに配置することで、インポート時のネットワークレイテンシーも低減されます。
次の図は、Amazon EC2 インスタンスへのデータベースバックアップのコピーを示しています。
![\[データベースのバックアップを Amazon EC2 インスタンスにコピーするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_3.png)
### Amazon EC2 インスタンスを作成し、データをコピーするには
1. Amazon RDS データベースを作成する予定の AWS リージョンに、仮想プライベートクラウド (VPC)、VPC セキュリティグループ、および VPC サブネットを作成します。VPC セキュリティグループのインバウンドルールで、アプリケーションが AWS に接続するために必要な IP アドレスを許可していることを確認します。IP アドレスの範囲 (`203.0.113.0/24` など) や別の VPC セキュリティグループを指定できます。[Amazon VPC コンソール](https://console.aws.amazon.com/vpc)を使用して、VPC、サブネット、セキュリティグループを作成および管理できます。詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[Amazon VPC の開始方法](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started)」を参照してください。
1. [Amazon EC2 管理コンソール](https://console.aws.amazon.com/ec2)を開き、Amazon EC2 インスタンスと Amazon RDS データベースの両方が含まれる AWS リージョンを選択します。ステップ 1 で作成した VPC、サブネット、セキュリティグループを使用して Amazon EC2 インスタンスを起動します。非圧縮の場合のデータベースバックアップファイルに十分なストレージを備えたインスタンスタイプを選択していることを確認します。Amazon EC2 インスタンスの詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon EC2 の使用を開始する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html)」を参照してください。
1. Amazon EC2 インスタンスから Amazon RDS データベースに接続するには、VPC セキュリティグループを編集します。EC2 インスタンスのプライベート IP アドレスを指定するインバウンドルールを追加します。このプライベート IP アドレスは、EC2 コンソールウィンドウの [**Instance**] ペインの [**Details**] タブで確認できます。VPC セキュリティグループを編集してインバウンドルールを追加するには、EC2 コンソールのナビゲーションペインの **[Security Groups]** (セキュリティグループ) でセキュリティグループを選択してから、EC2 インスタンスのプライベート IP アドレスを指定して MySQL または Aurora のインバウンドルールを追加します。VPC セキュリティグループにインバウンドルールを追加する方法については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[セキュリティグループのルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)」を参照してください。
1. ローカルシステムから Amazon EC2 インスタンスに、圧縮されたデータベースバックアップファイルをコピーします。必要に応じて `chmod` を使用して、Amazon EC2 インスタンスのターゲットディレクトリに対する書き込みアクセス許可があることを確認します。`scp` または Secure Shell (SSH) クライアントを使用してファイルをコピーできます。以下は `scp` コマンドの例です。
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**重要**
機密データをコピーするときは、必ず安全なネットワーク転送プロトコルを使用してください。
1. Amazon EC2 インスタンスに接続し、次のコマンドを使用して最新のアップデートと MariaDB クライアントツールをインストールします。
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -y
```
詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の Linux インスタンスの「[インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux)」および「MariaDB ドキュメント」の「[MariaDB Connectors](https://mariadb.com/docs/connectors)」を参照してください。
1. Amazon EC2 インスタンスに接続されている間に、データベースバックアップファイルを解凍します。次のコマンドはその例です。
+ SQL 出力を解凍するには、次のコマンドを使用します。
```
gzip backup.sql.gz -d
```
+ 区切り文字付きテキスト出力を解凍するには、次のコマンドを使用します。
```
tar xzvf backup.tar.gz
```
## タスク 3: MariaDB データベースを作成し、Amazon EC2 インスタンスからデータをインポートする
Amazon EC2 インスタンスと同じ AWS リージョンで RDS for MariaDB DB インスタンスを作成することによって、インターネット経由でインポートするよりも速く、Amazon EC2 からデータベースのバックアップファイルをインポートできます。
次の図は、Amazon EC2 インスタンスから MariaDB データベースにバックアップをインポートする様子を示しています。
![\[EC2 インスタンスから MariaDB データベースにバックアップをインポートするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### MariaDB データベースを作成し、データをインポートするには
1. この Amazon RDS データベースについて予想されるワークロードをサポートするのに必要な DB インスタンスクラスとストレージ領域の容量を決定します。このプロセスの一環として、データロードの手順に十分な領域と処理能力を決定します。また、本番稼働ワークロードの処理に必要なものも決定します。これは、ソースの MariaDB データベースのサイズおよびリソースに基づいて見積もることができます。詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
1. Amazon EC2 インスタンスを含む AWS リージョンに、DB インスタンスを作成します。「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」の指示に従い、次のガイドラインを使用します。
+ ソース DB インスタンスと互換性のある DB エンジンのバージョンを指定します。
+ Amazon EC2 インスタンスと同じ仮想プライベートクラウド (VPC) と VPC セキュリティグループを指定します。これにより、Amazon EC2 インスタンスと Amazon RDS インスタンスはネットワーク上で相互に表示されることが確認できます。DB インスタンスがパブリックにアクセスできることを確認してください。以下のセクションで説明するように、ソースデータベースでレプリケーションをセットアップするには、DB インスタンスにパブリックアクセス可能である必要があります。
+ データベースのバックアップのインポートが完了するまで、複数のアベイラビリティーゾーン、バックアップ保持、リードレプリカを設定しないでください。インポートが完了したら、本稼働インスタンスについて、マルチ AZ とバックアップ保持を設定できます。
1. Amazon RDS データベースのデフォルトの設定オプションを確認します。データベースのデフォルトパラメータグループに必要な設定オプションがない場合は、別のパラメータグループを検索するか、新しいパラメータグループを作成します。パラメータグループの作成の詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
1. マスターユーザーとして、新しい Amazon RDS データベースに接続します。DB インスタンスにアクセスする必要がある管理者、アプリケーション、およびサービスのサポートに必要なユーザーを作成します。Amazon RDS データベースのホスト名は、この DB インスタンスの **[エンドポイント]** の値からポート番号を除いた値 (例: `mysampledb.123456789012.us-west-2.rds.amazonaws.com`) です。エンドポイントの値は、Amazon RDS コンソールのデータベースの詳細で確認できます。
1. Amazon EC2 インスタンスに接続します。詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の Linux インスタンスの「[インスタンスをクリーンアップする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux)」を参照してください。
1. `mysql` コマンドを使用して、Amazon EC2 インスタンスからリモートホストとして Amazon RDS データベースに接続します。コマンドの例を次に示します。
```
mysql -h host_name -P 3306 -u db_master_user -p
```
*host\$1name* は、Amazon RDS データベースのエンドポイントです。
1. `mysql` プロンプトで、データベースダンプファイルの名前を渡して `source` コマンドを実行します。このコマンドは、Amazon RDS DB インスタンスにデータをロードします。
+ SQL 形式の場合は、次のコマンドを使用します。
```
MariaDB [(none)]> source backup.sql;
```
+ 区切り文字付きテキスト形式の場合は、Amazon RDS データベースをセットアップしたときに作成したデフォルトのデータベースではない場合、まず、データベースを作成します。
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
次にテーブルを作成します。
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
次にデータをインポートします。
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
パフォーマンスを向上させるために、複数の接続からこれらのオペレーションをパラレル実行して、すべてのテーブルを同時に作成およびロードすることができます。
**注記**
最初にテーブルをダンプした際、`mysqldump` または `mariadb-dump` でデータをフォーマットするオプションを使用した場合は、データファイルのコンテンツが適切に解釈できるように、`LOAD DATA LOCAL INFILE` でも必ず同じオプションを使用する必要があります。
1. インポートしたデータベースの単一のテーブルまたは 2 つのテーブルに対してシンプルな `SELECT` クエリを実行して、インポートが正常に完了したかを検証します。
この手順で使用された Amazon EC2 インスタンスが今後不要な場合は、EC2 インスタンスを終了して、AWS リソース使用率を減らします。EC2 インスタンスを終了するには、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[インスタンスの終了](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console)」を参照してください。
## タスク 4: 外部データベースから新しい Amazon RDS データベースにデータをレプリケートする
ソースデータベースは、データをコピーして MariaDB データベースに転送するまでに更新された可能性があります。レプリケーションを使用して、コピーしたデータベースをソースデータベースで最新のものにすることができます。
![\[外部 MariaDB データベースから Amazon RDS 上のデータベースにデータをレプリケートするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_5.png)
Amazon RDS データベースでレプリケーションを開始するために必要なアクセス許可は限定されており、Amazon RDS マスターユーザーは利用できません。このため、適切な Amazon RDS ストアドプロシージャを使用します。
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ レプリケーションを設定するには [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md)、レプリケーションを開始するには [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)
### レプリケーションをスタートするには
タスク 1 の[レプリケーションオプションの設定時](#mariadb-importing-data-reduced-downtime-set-replication-options)に、バイナリログ記録を有効にし、ソースデータベースに一意のサーバー ID を設定しました。これで、ライブデータベースをソースレプリケーションインスタンスとして、Amazon RDS データベースをレプリカとしてセットアップできます。
1. Amazon RDS コンソールで、ソースデータベースをホストするサーバーの IP アドレスを Amazon RDS データベースの VPC セキュリティグループに追加します。VPC セキュリティグループの詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[セキュリティグループのルールを設定する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)」を参照してください。
ソースインスタンスと通信できるためには、Amazon RDS データベースの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Amazon RDS データベースの IP アドレスを確認するには、`host` コマンドを使用します。
```
host host_name
```
*host\$1name* は、Amazon RDS データベースのエンドポイントの DNS 名 (例: `myinstance.123456789012.us-east-1.rds.amazonaws.com`) です。エンドポイントの値は、Amazon RDS コンソールの DB インスタンスの詳細で確認できます。
1. 選択したクライアントを使用して、ソースインスタンスに接続し、レプリケーションに使用するユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。コマンドの例を次に示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定してください。
1. ソースインスタンスについて、`REPLICATION CLIENT` と `REPLICATION SLAVE` の特権をレプリケーションユーザーに付与します。たとえば、すべてのデータベースに対する `REPLICATION CLIENT` と `REPLICATION SLAVE` の特権を、「`repl_user`」ユーザーに付与するには、次のコマンドを実行します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. SQL 形式を使用してバックアップファイルを作成しており、外部インスタンスが MariaDB 10.0.24 以降でない場合は、次のコマンドを実行してファイルのコンテンツを表示します。
```
cat backup.sql
```
このファイルに、マスターログファイルの名前と場所を示す `CHANGE MASTER TO` コメントが含まれています。`--master-data` で `mysqldump` オプションを使用した場合に、バックアップファイルにこのコメントが含まれます。`MASTER_LOG_FILE` と `MASTER_LOG_POS` の値に注意してください。
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
バックアップファイルの作成に区切りテキスト形式を使用しており、外部のインスタンスが MariaDB 10.0.24 以降でない場合は、[既存のデータベースのバックアップコピーの作成時に](#mariadb-importing-data-reduced-downtime-create-backup)、タスク 1 のステップ 1 でバイナリログ座標を既に取得しているはずです。
外部のインスタンスが MariaDB 10.0.24 以降の場合は、[既存のデータベースのバックアップコピーの作成時](#mariadb-importing-data-reduced-downtime-create-backup)に、タスク 1 のステップ 2 でレプリケーションを開始するための GTID を既に取得しているはずです。
1. Amazon RDS データベースをレプリカにします。外部のインスタンスが MariaDB 10.0.24 以降でない場合、マスターユーザーとして Amazon RDS データベースに接続し、[mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ストアドプロシージャを使用して、ソースのレプリケーションインスタンスとしてソースデータベースを特定します。
SQL 形式のバックアップファイルがある場合は、ステップ 4 で確認したマスターログのファイル名とマスターログの位置を使用します。区切り文字テキスト形式を使用した場合は、バックアップファイルの作成時に決定した名前と場所を使用します。コマンドの例を次に示します。
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定してください。
外部のインスタンスが MariaDB 10.0.24 以降の場合、マスターユーザーとして Amazon RDS データベースに接続し、[mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) ストアドプロシージャを使用して、ソースのレプリケーションインスタンスとしてソースデータベースを特定します。[既存のデータベースのバックアップコピーの作成時](#mariadb-importing-data-reduced-downtime-create-backup)に、タスク 1 のステップ 2 で確認した GTID を使用します。コマンドの例を次に示します。
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
`source_server_ip_address` は、ソースレプリケーションインスタンスの IP アドレスです。EC2 プライベート DNS アドレスは現在サポートされていません。
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定してください。
1. Amazon RDS データベースでレプリケーションを開始するには、[mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) ストアドプロシージャを使用する次のコマンドを実行します。
```
CALL mysql.rds_start_replication;
```
1. Amazon RDS データベースで、レプリカがいつソースレプリケーションインスタンスの最新の状態に更新されるかを特定するには、[SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) コマンドを実行します。`SHOW REPLICA STATUS` コマンドの結果には、`Seconds_Behind_Master` フィールドが含まれます。`Seconds_Behind_Master` フィールドが 0 を返す場合、レプリカはソースレプリケーションインスタンスで最新の状態になります。
MariaDB 10.5、10.6、10.11、11.4 または 11.8 DB インスタンスの場合は、MySQL コマンドを実行する代わりに [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) ストアドプロシージャを使用します。
1. Amazon RDS データベースが最新の状態になったら、必要に応じてデータベースを復元できるように、自動バックアップを有効にします。[Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を使用して、Amazon RDS データベースの自動バックアップを有効化または変更できます。詳細については、「[バックアップの概要](USER_WorkingWithAutomatedBackups.md)」を参照してください。
## タスク 5: ライブアプリケーションを Amazon RDS インスタンスにリダイレクトする
MariaDB データベースがソースレプリケーションインスタンスで最新の状態になったら、ライブアプリケーションを更新して、Amazon RDS インスタンスを使用できます。
![\[レプリケーションを停止し、ライブアプリケーションを Amazon RDS 上のデータベースにリダイレクトするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_6.png)
### ライブアプリケーションを MariaDB データベースにリダイレクトしてレプリケーションを停止するには
1. Amazon RDS データベースの VPC セキュリティグループを追加するには、アプリケーションをホストするサーバーの IP アドレスを追加します。VPC セキュリティグループの変更の詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[セキュリティグループのルールを設定する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)」を参照してください。
1. [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) コマンドの結果の `Seconds_Behind_Master` フィールドが 0 であることを確認します。この値は、レプリカがソースレプリケーションインスタンスの最新の状態であることを示します。
```
SHOW REPLICA STATUS;
```
MariaDB 10.5、10.6、10.11、11.4 または 11.8 DB インスタンスの場合は、MySQL コマンドを実行する代わりに [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) プロシージャを使用します。
1. トランザクションが終了したら、ソースへのすべての接続を閉じます。
1. Amazon RDS データベースを使用するようにアプリケーションを更新します。この更新には、一般に、Amazon RDS データベースのホスト名とポート、接続に使用するユーザーアカウントとパスワード、および使用するデータベースを識別する接続設定の変更が含まれます。
1. DB インスタンスに接続します。
1. [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) ストアドプロシージャを使用する次のコマンドを実行して、Amazon RDS インスタンスのレプリケーションを停止します。
```
CALL mysql.rds_stop_replication;
```
1. Amazon RDS データベースで [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) ストアドプロシージャを使用する次のコマンドを実行して、レプリケーション設定をリセットします。これにより、このインスタンスはレプリカとして識別されなくなります。
```
CALL mysql.rds_reset_external_master;
```
1. マルチ AZ のサポートやリードレプリカなど、Amazon RDS のその他の機能を有効にします。詳細については、「[Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md)」および「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
# 任意のソースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする
Amazon RDS を使用すると、既存の MariaDB データを任意のソースから RDS for MariaDB DB インスタンスに移行できます。オンプレミスデータベース、他のクラウドプロバイダー、または既存の RDS for MariaDB DB インスタンスからターゲット RDS for MariaDB DB インスタンスにデータを転送できます。この機能を使用すると、データベースの統合、ディザスタリカバリソリューションの実装、セルフマネージド型データベースからの移行を行うことができます。一般的なシナリオには、セルフホスト型の MariaDB サーバーからフルマネージド型の Amazon RDS DB インスタンスへの移行、複数の MariaDB データベースの 1 つの DB インスタンスへの統合、本番データを使用したテスト環境の作成などがあります。以下のセクションでは、`mariadb-dump`、バックアップファイル、レプリケーションなどのメソッドを使用して MariaDB データをインポートする詳細な手順について説明します。
## ステップ 1: ロードするデータを含むフラットファイルを作成する
カンマ区切り値 (CSV) などの一般的な形式を使用して、ロードするデータを保存します。各テーブルには独自のファイルが必要です。複数のテーブルのデータを同じファイルに結合することはできません。各ファイルに、対応するテーブルと同じ名前を付けます。ファイル拡張子は何でもかまいません。例えば、テーブル名が `sales` の場合、ファイル名は `sales.csv` または `sales.txt` になります。
可能であれば、ロードされるテーブルのプライマリキーでデータをソートします。これにより、ロード時間が大幅に短縮され、ディスクストレージの要件が最小限に抑えられます。
この手順の速度と効率は、ファイルのサイズを小さく保つかどうかによって決まります。個々のファイルの非圧縮サイズが 1 GiB を超える場合、複数のファイルに分割して、1 つずつロードしてください。
Unix のようなシステム (Linux など) では、`split` コマンドを使用します。例えば、次のコマンドでは `sales.csv` ファイルが 1 GiB 未満の複数のファイルに分割されます。ただし、分割されるのは改行でのみです (-C 1024m)。新しいファイルの名前には、昇順の数値サフィックスが含まれます。次のコマンドは、`sales.part_00` や `sales.part_01` などの名前のファイルを生成します。
```
split -C 1024m -d sales.csv sales.part_
```
他のオペレーティングシステムにも同様のユーティリティを使用できます。
フラットファイルはどこにでも保存できます。ただし、[ステップ 5](#mariadb-importing-data-any-source-load-data) でデータをロードするときは、ファイルが存在するのと同じ場所から `mysql` シェルを呼び出すか、`LOAD DATA LOCAL INFILE` の実行時にファイルの絶対パスを使用する必要があります。
## ステップ 2: ターゲット DB インスタンスにアクセスしているすべてのアプリケーションを停止する
大きなロードをスタートする前に、ロード先のターゲット DB インスタンスにアクセスするすべてのアプリケーションアクティビティを停止します。特に、他のセッションでロード中のテーブルや参照するテーブルを変更する場合は、これをお勧めします。これにより、ロード中に発生する制約違反のリスクが軽減され、ロードパフォーマンスが向上します。また、ロードに関係しないプロセスによって行われた変更を失うことなく、DB インスタンスをロードの直前の時点に復元することもできます。
もちろん、これは可能でない場合や実用的ではない場合があります。アプリケーションによる DB インスタンスへのアクセスをロード前に停止できない場合は、データの可用性と整合性を確保するための手順を実行してください。必要となる具体的なステップは、実際のユースケースとサイト要件によって大きく異なります。
## ステップ 3: DB スナップショットを作成する
データが含まれない新しい DB インスタンスにデータをロードする場合、このステップをスキップできます。それ以外の場合は、データロードの前後にターゲットの Amazon RDS DB インスタンスの DB スナップショットを作成することをお勧めします。Amazon RDS DB スナップショットは DB インスタンスの完全なバックアップであり、DB インスタンスを既知の状態に復元するために使用できます。DB スナップショットをスタートすると、データベースのバックアップのため DB インスタンスに対する I/O 操作が一時停止されます。
ロード直前に DB スナップショットを作成すると、必要が生じた場合にデータベースをロード前の状態に復元できます。ロード直後に DB スナップショットを作成しておくと、何らかの事故のときにそのスナップショットを使用すれば、データを再ロードせずに済みます。ロード後に DB スナップショットを使用して、新しいデータベースインスタンスにデータをインポートすることもできます。
次の例では、AWS CLI の [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) コマンドを実行して、`AcmeRDS` インスタンスの DB スナップショットを作成し、その DB スナップショットに識別子 `"preload"` を指定します。
Linux、macOS、Unix の場合:
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Windows の場合:
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
DB スナップショットからの復元機能を使用して、リハーサル用のテスト DB インスタンスを作成したり、ロード中に加えられた変更を元に戻すこともできます。
DB スナップショットからデータベースを復元すると、すべての DB インスタンスと同様に一意の識別子とエンドポイントを持つ新しい DB インスタンスが作成される点に留意してください。エンドポイントを変更せずに DB インスタンスを復元するには、エンドポイントを再利用できるように、まず DB インスタンスを削除します。
例えば、リハーサルや他のテスト用の DB インスタンスを作成するには、DB インスタンスに独自の識別子を指定します。この例での識別子は「`AcmeRDS-2`」です。この例では、`AcmeRDS-2` に関連付けられたエンドポイントを使用して DB インスタンスに接続します。詳細については、「[restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)」を参照してください。
Linux、macOS、Unix の場合:
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Windows の場合:
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
既存のエンドポイントを再利用するには、まず DB インスタンスを削除してから、復元されたデータベースに同じ識別子を指定します。詳細については、「[delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html)」を参照してください。
次の例でも、DB インスタンスを削除する前に最終的な DB スナップショットを取得しています。これはオプションですが推奨されます。
Linux、macOS、Unix の場合:
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Windows の場合:
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## ステップ 4 (オプション): Amazon RDS 自動バックアップをオフにする
**警告**
ポイントインタイムリカバリを実行する必要がある場合は、自動バックアップをオフにしないでください。
自動バックアップをオフにすると、パフォーマンスが最適化します。これはデータのロードに必須ではありません。自動バックアップをオフにすると、既存のバックアップがすべて消去されます。その結果、自動バックアップをオフにすると、ポイントインタイムリカバリができなくなります。自動バックアップを無効にしても、手動 DB スナップショットに影響が及ぶことはありません。既存のすべての手動 DB スナップショットは引き続き復元で使用可能です。
自動バックアップを無効にするとロード時間が約 25% 短縮し、ロード時に必要なストレージ容量が減少します。データが含まれない新しい DB インスタンスにデータをロードする場合、バックアップを無効にすると、ロードを簡単に高速化でき、バックアップに必要な追加のストレージを使用する必要がなくなります。しかし、状況によっては、既にデータが含まれている DB インスタンスにロードする場合もあります。その場合、バックアップを無効にするメリットと、ポイントインタイムリカバリを実行できなくなることの影響を比較検討する必要があります。
DB インスタンスでは、デフォルトで自動バックアップが有効になっています (保持期間は 1 日です)。自動バックアップを無効にするには、バックアップ保持期間を 0 に設定します。ロード後、バックアップ保持期間を 0 以外の値に設定することでバックアップを再度有効にすることができます。バックアップを有効または無効にするには、Amazon RDS で DB インスタンスをシャットダウンおよび再起動して、MariaDB のログ記録を有効または無効にします。
AWS CLI の `modify-db-instance` コマンドを実行し、バックアップ保持期間を 0 に設定して変更をすぐに適用します。保持期間を 0 に設定するには DB インスタンスを再起動する必要があるため、続行前に再起動が完了するまで待っています。詳細については、「[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)」を参照してください。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
AWS CLI の [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) コマンドで DB インスタンスのステータスを確認できます。次の例では、`AcmeRDS` DB インスタンスにおける DB インスタンスのステータスを表示します。
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
DB インスタンスのステータスが `available` になったら、次のステップに進む準備が整いました。
## ステップ 5: データをロードする
フラットファイルから行を読み取ってデータベーステーブルにロードするには、MariaDB の `LOAD DATA LOCAL INFILE` ステートメントを使用します。
**注記**
フラットファイルが存在するのと同じ場所から `mariadb` シェルを呼び出すか、`LOAD DATA LOCAL INFILE` の実行時にファイルの絶対パスを使用する必要があります。
次の例は、`sales.txt` という名前のファイルからデータベース内の `Sales` という名前のテーブルにデータをロードする方法を示しています。
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
`LOAD DATA` ステートメントの詳細については、「MariaDB ドキュメント」の「[LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile)」を参照してください。
## ステップ 6: Amazon RDS 自動バックアップを再度オンにする
[ステップ 4](#mariadb-importing-data-any-source-turn-off-automated-backups) で Amazon RDS 自動バックアップをオフにした場合は、ロードが完了したら、バックアップ保持期間をロード前の値に戻して、自動バックアップをオンにします。ステップ 4 で説明したように、Amazon RDS は DB インスタンスを再起動するため、短時間の停止に備えてください。
次の例では、AWS CLI の [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドを実行して、`AcmeRDS` DB インスタンスの自動バックアップをオンにします。保持期間は 1 日に設定します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```
# Amazon RDS での MariaDB のレプリケーションの使用
リードレプリカは通常、Amazon RDS の DB インスタンス間でレプリケーションを設定するために使用します。リードレプリカの概要については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。Amazon RDS for MariaDB でリードレプリカを操作する具体的な方法については、[MariaDB リードレプリカの使用](USER_MariaDB.Replication.ReadReplicas.md) を参照してください。
レプリケーションは、MariaDB DB インスタンスのバイナリログ座標に基づいて設定することもできます。MariaDB インスタンスでは、グローバルトランザクション ID (GTIDs) に基づいてより高度な耐クラッシュ性を提供するレプリケーションを設定できます。詳細については、「[外部ソースインスタンスを使用した GTID ベースのレプリケーションを設定する](MariaDB.Procedural.Replication.GTID.md)」を参照してください。
以下は RDS for MariaDB で使用できる他のレプリケーションオプションです。
+ RDS for MariaDB DB インスタンスと Amazon RDS の外部にある MySQL または MariaDB インスタンスとの間でレプリケーションを設定できます。外部ソースとのレプリケーションの設定については、「[外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定](MySQL.Procedural.Importing.External.ReplMariaDB.md)」を参照してください。
+ Amazon RDS の外部にある MySQL または MariaDB インスタンスからデータベースをインポートしたり、これらのインスタンスにデータベースをエクスポートしたりするようにレプリケーションを設定できます。詳細については、「[ダウンタイムを短縮して Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-reduced-downtime.md)」および「[レプリケーションを使用した MySQL DB インスタンスからのデータのエクスポート](MySQL.Procedural.Exporting.NonRDSRepl.md)」を参照してください。
これらのどのレプリケーションオプションでも、行ベース、ステートメントベース、または混合レプリケーションが使用できます。行ベースのレプリケーションは、SQL ステートメントの結果として変更された行のみをレプリケートします。ステートメントベースのレプリケーションは、SQL ステートメント全体をレプリケートします。混合レプリケーションは、可能な場合にはステートメントレプリケーションを使用しますが、ステートメントベースのレプリケーションに対して安全でない SQL ステートメントが実行されると、行ベースのレプリケーションに切り替えます。ほとんどの場合には、混合レプリケーションをお勧めします。DB インスタンスのバイナリログ形式は、レプリケーションが行ベース、ステートメントベース、混合のいずれであるかを判断します。バイナリログ形式の設定については、「[MariaDB バイナリログ記録の設定](USER_LogAccess.MariaDB.BinaryFormat.md)」を参照してください。
MariaDB バージョン間のレプリケーションの互換性については、MariaDB ドキュメントの「[レプリケーションの互換性](https://mariadb.com/kb/en/mariadb-vs-mysql-compatibility/#replication-compatibility)」を参照してください。
**Topics**
+ [MariaDB リードレプリカの使用](USER_MariaDB.Replication.ReadReplicas.md)
+ [外部ソースインスタンスを使用した GTID ベースのレプリケーションを設定する](MariaDB.Procedural.Replication.GTID.md)
+ [外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定](MySQL.Procedural.Importing.External.ReplMariaDB.md)
# MariaDB リードレプリカの使用
以下では、Amazon RDS for MariaDB でのリードレプリカの使用に関する特定の情報を確認することができます。リードレプリカと使用手順の概要については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
+ [MariaDB を使用したレプリケーションフィルターの設定](USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.md)
+ [MariaDB での遅延レプリケーションの設定](USER_MariaDB.Replication.ReadReplicas.DelayReplication.md)
+ [MariaDB でのリードレプリカの更新](USER_MariaDB.Replication.ReadReplicas.Updates.md)
+ [MariaDB でのマルチ AZ リードレプリカのデプロイの使用](USER_MariaDB.Replication.ReadReplicas.MultiAZ.md)
+ [RDS for MariaDB でのカスケードリードレプリカの使用](USER_MariaDB.Replication.ReadReplicas.Cascading.md)
+ [MariaDB リードレプリカのモニタリング](USER_MariaDB.Replication.ReadReplicas.Monitor.md)
+ [MariaDB リードレプリカでのレプリケーションの開始と停止](USER_MariaDB.Replication.ReadReplicas.StartStop.md)
+ [MariaDB リードレプリカの問題のトラブルシューティング](USER_ReadRepl.Troubleshooting.MariaDB.md)
## MariaDB でのリードレプリカの設定
MariaDB DB インスタンスがレプリケーションソースとして機能するには、バックアップ保持期間を 0 以外の値に設定することにより、ソース DB インスタンスで自動バックアップを有効にしてください。この要件は、別のリードレプリカのソース DB インスタンスであるリードレプリカにも適用されます。
同一リージョン内の 1 つの DB インスタンスから、最大 15 個のリードレプリカを作成できます。レプリケーションを効率的に行うには、各リードレプリカにソースの DB インスタンスと同程度のコンピューティングリソースとストレージリソースが必要です。ソースの DB インスタンスをスケールした場合は、リードレプリカもスケールする必要があります。
RDS for MariaDB では、リードレプリカのカスケードをサポートしています。リードレプリカのカスケードを設定する方法については、「[RDS for MariaDB でのカスケードリードレプリカの使用](USER_MariaDB.Replication.ReadReplicas.Cascading.md)」を参照してください。
同じソースの DB インスタンスを参照する複数のリードレプリカの作成や削除の操作は同時に実行できます。その操作を実行するには、ソースインスタンスごとに作成できるリードレプリカを 15 個に制限します。
# MariaDB を使用したレプリケーションフィルターの設定
レプリケーションフィルターを使用して、リードレプリカでレプリケートするデータベースとテーブルを指定できます。レプリケーションフィルターは、データベースとテーブルをレプリケーションに含めることも、レプリケーションから除外することもできます。
レプリケーションフィルターの使用例は以下のとおりです。
+ リードレプリカのサイズを縮小します。レプリケーションフィルタリングを使用すると、リードレプリカで必要のないデータベースとテーブルを除外できます。
+ セキュリティ上の理由から、データベースとテーブルをリードレプリカから除外するため。
+ 異なるリードレプリカで、特定のユースケースごとにさまざまなデータベースとテーブルを複製するため。例えば、分析やシャーディングに特定のリードレプリカを使用できます。
+ 異なる AWS リージョン にリードレプリカがある DB インスタンスで、異なる AWS リージョン に異なるデータベースまたはテーブルを複製する場合。
**注記**
また、レプリケーションフィルターを使用して、インバウンドのレプリケーショントポロジでレプリカとして設定されているプライマリ MariaDB DB インスタンスでレプリケートするデータベースとテーブルを指定することもできます。この設定の詳細については、「[外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定](MySQL.Procedural.Importing.External.Repl.md)」を参照してください。
**Topics**
+ [RDS for MariaDB のレプリケーションフィルターパラメータの設定](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Configuring)
+ [RDS for MariaDB のレプリケーションフィルターの制限](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Limitations)
+ [RDS for MariaDB のレプリケーションフィルターの例](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Examples)
+ [リードレプリカのレプリケーションフィルターを表示する](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Viewing)
## RDS for MariaDB のレプリケーションフィルターパラメータの設定
レプリケーションフィルターを構成するには、リードレプリカに次のレプリケーションフィルターのパラメータを設定します。
+ `replicate-do-db` - 指定したデータベースに変更を複製します。リードレプリカに対してこのパラメータを設定すると、パラメータで指定されたデータベースのみが複製されます。
+ `replicate-ignore-db` - 指定したデータベースに変更を複製しないでください。リードレプリカに `replicate-do-db` パラメータが設定されている場合、このパラメータは評価されません。
+ `replicate-do-table` -指定されたテーブルに変更を複製します。このパラメータをリードレプリカに設定した場合、パラメータで指定したテーブルのみが複製されます。また、`replicate-do-db` パラメータまたは `replicate-ignore-db` パラメータを設定する場合は、指定されたテーブルを含むデータベースをリードレプリカのレプリケーションに含める必要があります。
+ `replicate-ignore-table` – 指定したテーブルに変更を複製しないでください。リードレプリカに `replicate-do-table` パラメータが設定されている場合、このパラメータは評価されません。
+ `replicate-wild-do-table` - 指定したデータベースおよびテーブル名のパターンに基づいてテーブルを複製します。`%` および `_` ワイルドカードの文字がサポート対象となります。`replicate-do-db` または `replicate-ignore-db` パラメータが設定されている場合は、リードレプリカを使用して、指定したテーブルを含むデータベースをレプリケーションに含めるようにしてください。
+ `replicate-wild-ignore-table` - 指定したデータベースおよびテーブル名のパターンに基づいてテーブルを複製しないでください。`%` および `_` ワイルドカードの文字がサポート対象となります。リードレプリカに `replicate-do-table` または `replicate-wild-do-table` パラメータが設定されている場合、このパラメータは評価されません。
パラメータは、記載されている順序に沿って評価されます。これらのパラメータの詳細な仕組みについては、[MariaDB のドキュメント](https://mariadb.com/kb/en/replication-filters/#replication-filters-for-replication-slaves)を参照してください。
デフォルトでは、これらの各パラメータの値は空です。各リードレプリカで、これらのパラメータを使用してレプリケーションフィルターを設定、変更、削除することができます。これらのパラメータの 1 つを設定する場合は、各フィルターを他のフィルターとコンマで区切ります。
`%` および `_` パラメータで `replicate-wild-do-table` および `replicate-wild-ignore-table` ワイルドカードの文字を使用できます。`%` ワイルドカードは任意の文字数と一致し、`_` ワイルドカードは 1 文字のみと一致します。
ソース DB インスタンスのバイナリログ形式は、データ変更のレコードを決定するため、レプリケーションでは重要です。`binlog_format` パラメータの設定により、レプリケーションが行ベースかステートメントベースかが決まります。詳細については、「[MariaDB バイナリログ記録の設定](USER_LogAccess.MariaDB.BinaryFormat.md)」を参照してください。
**注記**
ソース DB インスタンスの `binlog_format` 設定に関係なく、すべてのデータ定義言語 (DDL) ステートメントはステートメントとして複製されます。
## RDS for MariaDB のレプリケーションフィルターの制限
RDS for MariaDB のレプリケーションフィルターには、次の制限が適用されます。
+ 各レプリケーションフィルターのパラメータには、2,000 文字といった制限があります。
+ レプリケーションフィルターでは、カンマはサポートされていません。
+ MariaDB `binlog_do_db` とバイナリログフィルターの `binlog_ignore_db` オプションはサポートされていません。
+ レプリケーションフィルタリングは、XA トランザクションをサポートしていません。
詳細については、MySQL ドキュメントの「[Restrictions on XA Transactions](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html)」を参照してください。
+ RDS for MariaDB バージョン 10.2 では、レプリケーションフィルターはサポートされていません。
## RDS for MariaDB のレプリケーションフィルターの例
リードレプリカのレプリケーションフィルタリングを構成するには、リードレプリカに関連付けられているパラメータグループのレプリケーションフィルタリングパラメータを変更します。
**注記**
デフォルトのパラメータグループを変更することはできません。リードレプリカがデフォルトのパラメータグループを使用している場合は、新しいパラメータグループを作成してリードレプリカに関連付けます。DB パラメータグループの詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
AWS マネジメントコンソール、AWS CLI、または RDS API を使用して、パラメータグループのパラメータを設定できます。パラメータの設定の詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。パラメータグループにパラメータを設定すると、そのパラメータグループに関連付けられているすべての DB インスタンスでパラメータ設定を使用します。パラメータグループにレプリケーションフィルターのパラメータを設定する場合は、パラメータグループがリードレプリカにのみ関連付けられていることを確認してください。ソース DB インスタンスのレプリケーションフィルターのパラメータは空のままにします。
次の例では、AWS CLI を使用してパラメータを設定します。これらの例では、CLI コマンドが完了した直後にパラメータの変更が行われるように `ApplyMethod` を `immediate` に設定しています。リードレプリカの再起動後に保留中の変更を適用する場合は、`ApplyMethod` を `pending-reboot` に設定します。
以下の例では、レプリケーションフィルターを設定します。
+ [Including databases in replication](#rep-filter-in-dbs-mariadb)
+ [Including tables in replication](#rep-filter-in-tables-mariadb)
+ [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mariadb)
+ [Escaping wildcard characters in names](#rep-filter-escape-wildcards-mariadb)
+ [Excluding databases from replication](#rep-filter-ex-dbs-mariadb)
+ [Excluding tables from replication](#rep-filter-ex-tables-mariadb)
+ [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mariadb)
**Example レプリケーションにデータベースを含める**
次の例では、レプリケーションに `mydb1` データベースと `mydb2` データベースが含まれています。リードレプリカに対して `replicate-do-db` を設定すると、パラメータで指定されたデータベースだけがレプリケートされます。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example レプリケーションにテーブルを含める**
次の例では、データベース `mydb1` の `table1` テーブルと `table2` テーブルをレプリケーションに含めています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example ワイルドカードの文字を使用してレプリケーションにテーブルを含める**
次の例では、データベース `mydb` の `orders` および `returns` で始まる名前のテーブルをレプリケーションに含めています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
**Example 名前のワイルドカード文字のエスケープ**
次の例は、エスケープ文字 `\` を使用して、名前の一部であるワイルドカードの文字をエスケープする方法を示しています。
データベース `mydb1` には `my_table` で始まる複数のテーブル名があり、これらのテーブルをレプリケーションに含めることを想定しています。テーブル名には、ワイルドカードの文字でもあるアンダースコアが含まれているため、この例ではテーブル名のアンダースコアをエスケープしています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
**Example レプリケーションからデータベースを除外する**
次の例では、`mydb1` データベースと `mydb2` データベースをレプリケーションから除外しています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example レプリケーションからテーブルを除外する**
次の例では、データベース `table1` のテーブル `table2` と `mydb1` をレプリケーションから除外しています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example ワイルドカードの文字を使用したレプリケーションからテーブルを除外する**
次の例では、データベース `mydb` の `orders` および `returns` で始まる名前のテーブルをレプリケーションから除外しています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
## リードレプリカのレプリケーションフィルターを表示する
リードレプリカのレプリケーションフィルターは、次の方法で表示できます。
+ リードレプリカに関連付けられているパラメータグループのレプリケーションフィルタリングパラメータの設定を確認してください。
手順については、「[Amazon RDS のDB パラメータグループのパラメータ値の表示](USER_WorkingWithParamGroups.Viewing.md)」を参照してください。
+ MariaDB クライアントで、リードレプリカに接続し、`SHOW REPLICA STATUS` ステートメントを実行します。
出力の次のフィールドには、リードレプリカのレプリケーションフィルターが表示されます。
+ `Replicate_Do_DB`
+ `Replicate_Ignore_DB`
+ `Replicate_Do_Table`
+ `Replicate_Ignore_Table`
+ `Replicate_Wild_Do_Table`
+ `Replicate_Wild_Ignore_Table`
これらのフィールドの詳細については、MySQL のドキュメントの [Checking Replication Status](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) を参照してください。
**注記**
MariaDB の旧バージョンは、`SHOW SLAVE STATUS` ではなく `SHOW REPLICA STATUS` を使用していました。10.5 より前の MariaDB バージョンを使用している場合は、`SHOW SLAVE STATUS` を使用します。
# MariaDB での遅延レプリケーションの設定
遅延レプリケーションは、災害対策用の戦略として使用できます。遅延レプリケーションでは、ソースからリードレプリカへのレプリケーションを遅延させる最小時間を秒数で指定します。障害発生時 (意図しないテーブルの削除など) には、以下のステップを実行して障害から早急に復旧します。
+ 障害を起こした変更がリードレプリカに送られる前に、リードレプリカへのレプリケーションを停止します。
レプリケーションを停止するには、[mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) ストアドプロシージャを使用します。
+ 「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」の手順を使用してリードレプリカを新しいソースの DB インスタンスに昇格させます。
**注記**
遅延レプリケーションは MariaDB 10.6 以降でサポートされています。
遅延レプリケーションを設定するには、ストアドプロシージャを使用します。遅延レプリケーションを AWS マネジメントコンソール、AWS CLI、または Amazon RDS API で設定することはできません。
遅延レプリケーションの設定でグローバルなトランザクション識別子 (GTID) に基づくレプリケーションを使用できます。
**Topics**
+ [リードレプリカ作成時の遅延レプリケーションの設定](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ReplicaCreation)
+ [既存のリードレプリカの遅延レプリケーションの変更](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ExistingReplica)
+ [リードレプリカの昇格](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.Promote)
## リードレプリカ作成時の遅延レプリケーションの設定
DB インスタンスから今後作成するリードレプリカの遅延レプリケーションを設定するには、[mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) パラメータを指定して `target delay` ストアドプロシージャを実行します。
**リードレプリカの作成時に遅延レプリケーションを設定するには**
1. MariaDB クライアントを使用して、マスターユーザーとしてリードレプリカのソースとなる MariaDB DB インスタンスに接続します。
1. [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) パラメータを指定して `target delay` ストアドプロシージャを実行します。
例えば、現在の DB インスタンスから作成されるリードレプリカへのレプリケーションを少なくとも 1 時間 (3600 秒) 遅延させるように指定するには、次のストアドプロシージャを実行します。
```
call mysql.rds_set_configuration('target delay', 3600);
```
**注記**
このストアドプロシージャを実行すると、AWS CLI または Amazon RDS API を使用して作成したリードレプリカには、指定した秒数で遅延するレプリケーションが設定されます。
## 既存のリードレプリカの遅延レプリケーションの変更
既存のリードレプリカの遅延レプリケーションを変更するには、[mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) ストアドプロシージャを実行します。
**既存のリードレプリカの遅延レプリケーションを変更するには**
1. MariaDB クライアントを使用して、マスターユーザーとしてリードレプリカに接続します。
1. レプリケーションを停止するには、[mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) ストアドプロシージャを使用します。
1. [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) ストアドプロシージャを実行します。
例えば、リードレプリカへのレプリケーションを少なくとも 1 時間 (3600 秒) 遅延させるように指定するには、次のストアドプロシージャを実行します。
```
call mysql.rds_set_source_delay(3600);
```
1. [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) ストアドプロシージャを使用してレプリケーションを開始します。
## リードレプリカの昇格
レプリケーションが停止したら、災害対策シナリオでリードレプリカを新しいソース DB インスタンスに昇格させます。リードレプリカの昇格については、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
# MariaDB でのリードレプリカの更新
リードレプリカは読み取りクエリをサポートするように設計されていますが、ときどき更新が必要になることがあります。例えば、インデックスを追加して、レプリカにアクセスする特定のタイプのクエリを高速化する必要が生じることがあります。更新を有効にするには、リードレプリカの DB パラメータグループで `read_only` パラメータを **0** に設定します。
# MariaDB でのマルチ AZ リードレプリカのデプロイの使用
リードレプリカは、シングル AZ DB インスタンス配置からもマルチ AZ DB インスタンス配置からも作成できます。重要なデータの耐久性の高いと可用性を高めるにはマルチ AZ 配置を使用しますが、読み取り専用クエリを処理するためにマルチ AZ セカンダリを使用することはできません。代わりに、トラフィックの多いマルチ AZ DB インスタンスのリードレプリカを作成して、読み取り専用クエリをオフロードできます。マルチ AZ 配置のソースのインスタンスがセカンダリにフェイルオーバーすると、関連付けられているすべてのリードレプリカが (プライマリから) セカンダリをレプリケーションのソースとして使用するように自動的に切り替わります。詳細については、「[Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md)」を参照してください。
リードレプリカは、マルチ AZ DB インスタンスとして作成できます。Amazon RDS では、レプリカのフェイルオーバーをサポートするため、別のアベイラビリティーゾーンにレプリカのスタンバイを作成します。リードレプリカは、ソースのデータベースがマルチ AZ DB インスタンスであるかどうかに関係なく、マルチ AZ DB インスタンスとして作成できます。
# RDS for MariaDB でのカスケードリードレプリカの使用
RDS for MariaDB では、リードレプリカのカスケードをサポートしています。*カスケードリードレプリカ*により、ソースの RDS for MariaDB DB インスタンスにオーバーヘッドを追加せずに読み取りをスケーリングできます。
カスケードリードレプリカを使用すると、RDS for MariaDB DB インスタンスは、チェーン内の最初のリードレプリカにデータを送信します。その後、そのリードレプリカは、チェーン内の 2 番目のレプリカにデータを送信し、その動作が順に続いていきます。その結果、チェーン内のすべてのリードレプリカに RDS for MariaDB DB インスタンスの更新が送信されますが、ソース DB インスタンスでのオーバーヘッドは発生しません。
ソースの RDS for MariaDB DB インスタンスから、チェーン内にリードレプリカを 3 層まで作成できます。例えば、RDS for MariaDB DB インスタンス、`mariadb-main` があるとします。以下の操作を行うことができます。
+ `mariadb-main` で開始し、チェーン内に最初のリードレプリカ、`read-replica-1` を作成します。
+ 次に、`read-replica-1` で、チェーン内に次のリードレプリカ、`read-replica-2` を作成します。
+ 最後に、`read-replica-2` で、チェーン内に 3 番目のリードレプリカ、`read-replica-3` を作成します。
`mariadb-main` の層では、この 3 番目のカスケードリードレプリカに続く、別のリードレプリカを作成することはできません。一連の完全なインスタンス (RDS for MariaDB のソース DB インスタンスから、この層の最後のカスケードリードレプリカまで) は、最大 4 つの DB インスタンスで構成できます。
リードレプリカのカスケードを設定するには、RDS for MariaDB DB インスタンスで自動バックアップを有効にします。リードレプリカで自動バックアップを有効にするには、まずリードレプリカを作成し、次に自動バックアップを有効にするようにリードレプリカを変更します。詳細については、「[リードレプリカの作成](USER_ReadRepl.Create.md)」を参照してください。
他のリードレプリカと同様に、カスケードの一部となっているリードレプリカを昇格できます。リードレプリカのチェーン内でリードレプリカを昇格させると、そのレプリカはチェーンから削除されます。例えば、`mariadb-main` DB インスタンスのワークロードの一部を、経理部のみが使用する新しいインスタンスに移動するとします。この例では、3 つのリードレプリカから成るチェーンがあると仮定し、`read-replica-2` を昇格させることにします。チェーンは以下のような影響を受けます。
+ 昇格する `read-replica-2` は、レプリケーションチェーンから削除されます。
+ このリードレプリカは、完全な読み取り/書き込み DB インスタンスになります。
+ 昇格前と同じように、`read-replica-3` へのレプリケーションを継続します。
+ `mariadb-main` は、`read-replica-1` へのレプリケーションを継続します。
リードレプリカの昇格についての詳細は、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
# MariaDB リードレプリカのモニタリング
MariaDB のリードレプリカでは、Amazon CloudWatch で Amazon RDS の `ReplicaLag` メトリクスを確認することでレプリケーションの遅延をモニタリングできます。`ReplicaLag` メトリクスには、`Seconds_Behind_Master` コマンドの `SHOW REPLICA STATUS` フィールドの値が報告されます。
**注記**
MariaDB の旧バージョンは、`SHOW SLAVE STATUS` ではなく `SHOW REPLICA STATUS` を使用していました。10.5 より前の MariaDB バージョンを使用している場合は、`SHOW SLAVE STATUS` を使用します。
MariaDB のレプリケーション遅延の一般的な原因は以下のとおりです。
+ ネットワークが停止している。
+ リードレプリカで、インデックスがあるテーブルに書き込んでいる。`read_only` パラメータがリードレプリカで 0 に設定されていない場合、レプリケーションが中断されることがあります。
+ MyISAM などの非トランザクションストレージエンジンを使用している。レプリケーションは、MariaDB 上の InnoDB ストレージエンジンでのみサポートされます。
`ReplicaLag` メトリックが 0 に達すると、レプリカがソース DB インスタンスに追いついています。`ReplicaLag` メトリクスにより -1 が返された場合、レプリケーションは現在アクティブではありません。`ReplicaLag` = -1 は `Seconds_Behind_Master` = `NULL` と同等です。
# MariaDB リードレプリカでのレプリケーションの開始と停止
システムのストアドプロシージャ [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) および [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) を呼び出すことにより、Amazon RDS DB インスタンスでレプリケーションプロセスを停止して再スタートすることができます。これは、大きいインデックスの作成など、長時間実行されている操作の 2 つの Amazon RDS インスタンス間でレプリケーションするときに実行できます。レプリケーションは、データベースをインポートまたはエクスポートするときに停止してスタートする必要もあります。詳細については、「[ダウンタイムを短縮して Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-reduced-downtime.md)」および「[レプリケーションを使用した MySQL DB インスタンスからのデータのエクスポート](MySQL.Procedural.Exporting.NonRDSRepl.md)」を参照してください。
レプリケーションを手動で停止するかレプリケーションエラーで停止してから連続して 30 日を超えると、Amazon RDS はソースの DB インスタンスとすべてのリードレプリカの間のレプリケーションを終了します。これは、ソース DB インスタンスでの所要ストレージの増大と長期間のフェイルオーバーを防ぐためです。リードレプリカの DB インスタンスは引き続き使用できます。ただし、レプリケーションが終了されるとリードレプリカに必要なバイナリログがソースの DB インスタンスから削除されるため、レプリケーションを再開することはできません。レプリケーションを再度行うには、ソースの DB インスタンスの新しいリードレプリカを作成します。
# MariaDB リードレプリカの問題のトラブルシューティング
MariaDB のレプリケーションテクノロジーは非同期です。非同期であるため、ソースの DB インスタンスの `BinLogDiskUsage` やリードレプリカの `ReplicaLag` が増加する場合があります。例えば、ソース DB インスタンスへの大量の書き込みオペレーションは並行して実行できます。一方、リードレプリカへの書き込みオペレーションは単一の I/O スレッドでシリアルで行われるため、ソースのインスタンスとリードレプリカの間で遅延が発生する場合があります。MariaDB ドキュメントの読み取り専用のレプリカについては、「[レプリケーションの概要](http://mariadb.com/kb/en/mariadb/replication-overview/)」を参照してください。
ソースの DB インスタンスに対する更新とそれに続くリードレプリカに対する更新の間の遅延を低減するには、次のいくつかの方法があります。
+ ストレージサイズと DB インスタンスクラスがソース DB インスタンスと同程度となるようにリードレプリカのサイズを決定します。
+ ソース DB インスタンスとリードレプリカにより使用される DB パラメータグループのパラメータ設定に互換性を確保します。詳細と例については、このセクションの後方にある `max_allowed_packet` パラメータの説明を参照してください。
Amazon RDS は、リードレプリカのレプリケーションの状態をモニタリングし、何らかの理由でレプリケーションが停止した場合はリードレプリカのインスタンスの `Replication State` フィールドを `Error` に更新します。これには、リードレプリカで実行された DML クエリがソースの DB インスタンスで行われた更新と競合した場合などがあります。
[`Replication Error`] フィールドを参照することで、MariaDB エンジンによりスローされた関連エラーの詳細を確認できます。リードレプリカのステータスを示すイベントが生成されます（[RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045)、[RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046)、[RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047) など）。イベントについてとイベントへのサブスクライブの詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。MariaDB エラーメッセージが返された場合、『[MariaDB のエラーメッセージドキュメント](http://mariadb.com/kb/en/mariadb/mariadb-error-codes/)』でエラーを確認してください。
レプリケーションエラーを引き起こす一般的な問題は、リードレプリカの `max_allowed_packet` パラメータの値がソース DB インスタンスの `max_allowed_packet` パラメータより小さいことです。`max_allowed_packet` パラメータは、DB パラメータグループに設定できるカスタムパラメータで、データベースで実行できる DML コードの最大サイズを指定するために使用されます。場合によっては、ソースの DB インスタンスに関連付けらている DB パラメータグループの `max_allowed_packet` パラメータの値が、ソースのリードレプリカに関連付けられている DB パラメータグループの `max_allowed_packet` パラメータの値より小さいことがあります。このような場合、レプリケーションプロセスからエラー (パケットが 'max\$1allowed\$1packet' バイトを超える) がスローされ、レプリケーションが停止することがあります。ソースとリードレプリカで同じ `max_allowed_packet` パラメータ値を持つ DB パラメータグループが使用されるように設定することにより、エラーを修正できます。
レプリケーションエラーを引き起こす可能性があります他の一般的な状況は次のとおりです。
+ リードレプリカのテーブルに書き込んでいる。リードレプリカでインデックスを作成する場合、`read_only` パラメータを **0** に設定してインデックスを作成する必要があります。リードレプリカのテーブルに書き込んだ場合、レプリケーションが中断する可能性があります。
+ MyISAM. などの非トランザクションストレージエンジンを使用している。リードレプリカにはトランザクションストレージエンジンが必要です。レプリケーションは、MariaDB 上の InnoDB ストレージエンジンでのみサポートされます。
+ `SYSDATE()` など、安全でない非決定的クエリを使用している。詳細については、「[バイナリロギングでの安全および安全でないステートメントの判断](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html)」を参照してください。
エラーを安全にスキップできると判断した場合、[RDS for MySQL の現在のレプリケーションエラーのスキップ](Appendix.MySQL.CommonDBATasks.SkipError.md) で説明されているステップに従うことができます。それ以外の場合は、リードレプリカを削除し、同じ DB インスタンス識別子を使用してインスタンスを作成することで、エンドポイントを前のリードレプリカと同じままにすることができます。レプリケーションエラーが解決すると、[`Replication State`] は *[レプリケーション中]* に変化します。
MariaDB DB インスタンスでは、障害時にバイナリログ (binlog) のイベントがフラッシュされない場合、リードレプリカをセカンダリに切り替えられないことがあります。その場合、リードレプリカを手動で削除して作成し直します。次のパラメータ値 (`sync_binlog=1`、`innodb_flush_log_at_trx_commit=1`) を設定することで、これが発生する可能性を減らすことができます。これらの設定によりパフォーマンスが低下することがあるため、本稼働環境で変更を実装する前に影響をテストしてください。
# 外部ソースインスタンスを使用した GTID ベースのレプリケーションを設定する
バージョン 10.0.24 以降の外部 MariaDB インスタンスから RDS for MariaDB DB インスタンスへのグローバルなトランザクション識別子 (GTID) に基づいてレプリケーションを設定できます。Amazon RDS で外部ソースインスタンスとレプリカをセットアップする場合は、次のガイドラインに従ってください。
+ レプリカである RDS for MariaDB の DB インスタンスのフェイルオーバーイベントをモニタリングします。フェイルオーバーが発生すると、レプリカである DB インスタンスが、新しいホスト上に別のネットワークアドレスで再作成されます。フェイルオーバーイベントをモニタリングする方法については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
+ ソースインスタンスのバイナリログ (binlog) は、それらがレプリカに適用されていることを確認するまで保持します。このメンテナンスによって、障害発生時にソースインスタンスを復元できます。
+ Amazon RDS にある MariaDB DB インスタンスの自動バックアップを有効にします。自動バックアップを有効にすると、ソースインスタンスとレプリカを再同期する必要がある場合に、特定の時点にレプリカを復元できます。バックアップとポイントインタイム復元の詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
**注記**
MariaDB DB インスタンスでレプリケーションを開始するために必要なアクセス権限は限定されており、Amazon RDS マスターユーザーは利用できません。このため、Amazon RDS の [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) コマンドと [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) コマンドを使用して、ライブデータベースと RDS for MariaDB データベースとのレプリケーションを設定する必要があります。
外部のソースインスタンスと Amazon RDS 上の MariaDB DB インスタンス間でレプリケーションを開始するには、次の手順に従います。
**レプリケーションを開始するには**
1. ソース MariaDB インスタンスを読み取り専用にします。
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. 外部 MariaDB インスタンスの現在の GTID を取得します。`mysql` または選択したクエリエディタを使用して `SELECT @@gtid_current_pos;` を実行することで、取得できます。
GTID は、`--` の形式となります。一般的な GTID は **0-1234510749-1728** のようになります。GTID とコンポーネントパートの詳細については、MariaDB ドキュメントの「[グローバルトランザクション ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/)」を参照してください。
1. `mysqldump` を使用して、外部 MariaDB インスタンスから MariaDB DB インスタンスにデータベースをコピーします。非常に大きなデータベースでは、「[ダウンタイムを短縮して Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-reduced-downtime.md)」の手順を使用することが必要になる場合があります。
Linux、macOS、Unix の場合:
```
mysqldump \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Windows の場合:
```
mysqldump ^
--databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary \
-u local_user \
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**注記**
`-p` オプションと入力するパスワードの間にスペースがないことを確認します。
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
`--host` コマンドで、`--user (-u)`、`--port`、`-p`、`mysql` オプションを使用して、MariaDB DB インスタンスに接続するためのホスト名、ユーザー名、ポート、パスワードを指定します。ホスト名は MariaDB DB インスタンスのエンドポイントの DNS 名 (例: `myinstance.123456789012.us-east-1.rds.amazonaws.com`) です。エンドポイントの値は、Amazon RDS マネジメントコンソールのインスタンスの詳細で確認できます。
1. もう一度ソース MariaDB インスタンスを書き込み可能にします。
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
1. Amazon RDS マネジメントコンソールで、外部の MariaDB データベースをホストするサーバーの IP アドレスを、MariaDB DB インスタンスの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、*Amazon Virtual Private Cloud ユーザーガイド*の「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
以下の条件が満たされると、IP アドレスが変更される場合があります。
+ 外部ソースインスタンスと DB インスタンス間の通信にパブリック IP アドレスを使用している。
+ 外部ソースインスタンスが停止して再起動した。
これらの条件が満たされている場合は、追加する前に IP アドレスを確認してください。
外部の MariaDB インスタンスと通信可能にするために、MariaDB DB インスタンスの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。MariaDB の DB インスタンスの IP アドレスを確認するには、`host` コマンドを使用します。
```
host db_instance_endpoint
```
ホスト名は MariaDB DB インスタンスのエンドポイントの DNS 名です。
1. 選択したクライアントを使用して、外部の MariaDB インスタンスに接続し、レプリケーションに使用される MariaDB ユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。以下に例を示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. 外部の MariaDB インスタンスについて、`REPLICATION CLIENT` と `REPLICATION SLAVE` の特権をレプリケーションユーザーに付与します。例えば、すべてのデータベースに対する `REPLICATION CLIENT` および `REPLICATION SLAVE` 権限を "`repl_user`" ユーザーに付与するには、以下のコマンドを実行します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. MariaDB DB インスタンスをレプリカにします。MariaDB DB インスタンスにマスターユーザーとして接続し、[mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) コマンドを使用して、外部の MariaDB データベースをレプリケーションソースインスタンスとして指定します。ステップ 2 で決定した GTID を使用します。以下に例を示します。
```
CALL mysql.rds_set_external_master_gtid ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'GTID', 1);
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. MariaDB DB インスタンスで、[mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) コマンドを実行してレプリケーションを開始します。
```
CALL mysql.rds_start_replication;
```
# 外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定
バイナリログファイルのレプリケーションを使用して、RDS for MySQLまたは MariaDB DB インスタンスと Amazon RDS の外部にある MySQL または MariaDB インスタンスとの間でレプリケーションを設定できます。
**Topics**
+ [開始する前に](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin)
+ [外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定](#MySQL.Procedural.Importing.External.Repl.Procedure)
## 開始する前に
レプリケートされたトランザクションのバイナリログファイルの位置を使用して、レプリケーションを設定できます。
Amazon RDS DB インスタンスでレプリケーションをスタートするために必要なアクセス権限は限定されており、Amazon RDS マスターユーザーは利用できません。そのため、Amazon RDS の [mysql.rds\$1set\$1external\$1master (RDS for MariaDB および RDS for MySQL メジャーバージョン 8.0 以前)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) または [mysql.rds\$1set\$1external\$1source (RDS for MySQL メジャーバージョン 8.4 以降)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)、および [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) コマンドを使用して、ライブデータベースと Amazon RDS のデータベースのレプリケーションを設定する必要があります。
MySQL または MariaDB データベースにバイナリログ形式を設定するには、`binlog_format` パラメータを更新します。DB インスタンスがデフォルト DB インスタンスパラメータグループを使用している場合、新しい DB パラメータグループを作成して `binlog_format` パラメータを変更します。MariaDB および MySQL 8.0 以前のバージョンでは、`binlog_format` のデフォルトは `MIXED` です。ただし、特定バイナリログ (binlog) 形式が必要な場合は `binlog_format` を `ROW` または `STATEMENT` に設定する必要もあります。変更を適用するには、DB インスタンスを再起動します。MySQL 8.4 以降のバージョンでは、`binlog_format` のデフォルトは `ROW` です。
`binlog_format` パラメータの設定については、[シングル AZ データベースの RDS for MySQL バイナリログの設定](USER_LogAccess.MySQL.BinaryFormat.md) を参照してください。さまざまな MySQL レプリケーションタイプの詳細については、MySQL ドキュメントの「[ステートメントベースおよび行ベースレプリケーションのメリットとデメリット](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html)」を参照してください。
## 外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定
Amazon RDS で外部ソースインスタンスとレプリカをセットアップする場合は、次のガイドラインに従ってください。
+ レプリカである Amazon RDS DB インスタンスのフェイルオーバーのイベントをモニタリングします。フェイルオーバーが発生すると、レプリカである DB インスタンスが、新しいホスト上に別のネットワークアドレスで再作成されます。フェイルオーバーイベントをモニタリングする方法については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
+ ソースインスタンスのバイナリログがレプリカに適用されたことを確認するまで、これらのバイナリログを保持します。このメンテナンスによって、障害発生時にソースインスタンスを復元できます。
+ Amazon RDS DB インスタンスにある自動バックアップを有効にします。自動バックアップを有効にすると、ソースインスタンスとレプリカを再同期する必要がある場合に、特定の時点にレプリカを復元できます。バックアップと特定の時点への復元の詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
**外部ソースインスタンスを使用してバイナリログファイルのレプリケーションを設定するには**
1. ソース MySQL または MariaDB インスタンスを読み取り専用にします。
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. ソース MySQL または MariaDB インスタンスで `SHOW MASTER STATUS` コマンドを実行して、binlog の場所を特定します。
次の例のような出力を受け取ります。
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. `mysqldump` を使用して、外部のインスタンスから Amazon RDS DB インスタンスにデータベースをコピーします。非常に大きなデータベースでは、「[ダウンタイムを短縮して Amazon RDS for MySQL データベースにデータをインポートする](mysql-importing-data-reduced-downtime.md)」の手順を使用することが必要になる場合があります。
Linux、macOS、Unix の場合:
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Windows の場合:
```
mysqldump --databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**注記**
`-p` オプションと入力するパスワードの間にスペースがないことを確認します。
Amazon RDS DB インスタンスに接続するためのホスト名、ユーザー名、ポート、およびパスワードを指定するには、`--host` コマンドで `--user (-u)`、`--port`、`-p` および `mysql` オプションを使用します。ホスト名は、Amazon RDS DB インスタンスのエンドポイントのドメインネームサービス (DNS) 名 (例: `myinstance.123456789012.us-east-1.rds.amazonaws.com`) です。エンドポイントの値は、AWS マネジメントコンソール のインスタンスの詳細で確認できます。
1. もう一度ソース MySQL または MariaDB インスタンスを書き込み可能にします。
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
レプリケーションで使用するバックアップの作成の詳細については、[MySQL ドキュメント](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html)を参照してください。
1. AWS マネジメントコンソール で、外部のデータベースをホストするサーバーの IP アドレスを、Amazon RDS DB インスタンスの仮想プライベートクラウド (VPC) のセキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、*Amazon Virtual Private Cloudユーザーガイド*の「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
以下の条件が満たされると、IP アドレスが変更される場合があります。
+ 外部ソースインスタンスと DB インスタンス間の通信にパブリック IP アドレスを使用している。
+ 外部ソースインスタンスが停止して再起動した。
これらの条件が満たされている場合は、追加する前に IP アドレスを確認してください。
Amazon RDS の DB インスタンスの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。これは、ローカルネットワークから外部の MySQL または MariaDB インスタンスと通信できるようにするためです。Amazon RDS DB インスタンスの IP アドレスを確認するには、`host` コマンドを使用します。
```
host db_instance_endpoint
```
ホスト名は Amazon RDS DB インスタンスのエンドポイントの DNS 名です。
1. 選択したクライアントを使用して、外部のインスタンスに接続し、レプリケーションに使用される ユーザーを作成します。このアカウントをレプリケーション専用に使用し、セキュリティを強化するためドメインに制限します。以下に例を示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. 外部の インスタンスについて、`REPLICATION CLIENT` と `REPLICATION SLAVE` の特権をレプリケーションユーザーに付与します。例えば、すべてのデータベースに対する `REPLICATION CLIENT` および `REPLICATION SLAVE` 権限を "`repl_user`" ユーザーに付与するには、以下のコマンドを実行します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Amazon RDS DB インスタンスをレプリカにします。これを行うには、まず、マスターユーザーとして Amazon RDS の DB インスタンスに接続します。次に、[mysql.rds\$1set\$1external\$1source (RDS for MySQL メジャーバージョン 8.4 以降)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) または [mysql.rds\$1set\$1external\$1master (RDS for MariaDB および RDS for MySQL メジャーバージョン 8.0 以前)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) のコマンドを使用して、外部の MySQL または MariaDB データベースをソースインスタンスとして指定します。ステップ 2 で特定したマスターログファイル名とマスターログの場所を使用します。次のコマンドはその例です。
**MySQL 8.4**
```
CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MariaDB と MySQL 8.0 および 5.7**
```
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**注記**
RDS for MySQL では、代わりに [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL メジャーバージョン 8.4 以降)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) または [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB および RDS for MySQL メジャーバージョン 8.0 以前)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay) のストアドプロシージャを実行することで、遅延レプリケーションを使用するよう選択できます。RDS for MySQL で遅延レプリケーションを使用する 1 つの理由は、[mysql.rds\$1start\$1replication\$1until](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ストアドプロシージャで災害対策を有効にするためです。現在、RDS for MariaDB では遅延レプリケーションはサポートされていますが、`mysql.rds_start_replication_until` プロシージャはサポートされていません。
1. Amazon RDS DB インスタンスで、[mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) コマンドを実行してレプリケーションをスタートします。
```
CALL mysql.rds_start_replication;
```
# MariaDB データベースエンジンのオプション
ここでは、MariaDB DB エンジンを実行する Amazon RDS インスタンスで使用できるオプションまたは追加機能について説明します。これらのオプションをオンにするには、カスタムオプショングループにオプションを追加して、そのオプショングループを DB インスタンスに関連付けます。オプショングループの操作方法の詳細については、「[オプショングループを使用する](USER_WorkingWithOptionGroups.md)」を参照してください。
Amazon RDS では、以下の MariaDB 用オプションがサポートされています。
| オプション ID | エンジンバージョン |
| --- | --- |
| `MARIADB_AUDIT_PLUGIN` | MariaDB 10.3 以降 |
## MariaDB 監査プラグインのサポート
Amazon RDS では、MariaDB データベースインスタンスでの MariaDB 監査プラグインの使用をサポートしています。MariaDB 監査プラグインは、データベースへのユーザーのログオンやデータベースに対して実行されたクエリなどのデータベースアクティビティを記録します。データベースのアクティビティのレコードはログファイルに保存されます。
### 監査プラグインのオプション設定
Amazon RDS では、MariaDB 監査プラグインのオプションの次の設定がサポートされています。
**注記**
RDS コンソールでオプション設定を構成しない場合、RDS はデフォルト設定を使用します。
| オプション設定 | 有効な値 | デフォルト値 | 説明 |
| --- | --- | --- | --- |
| `SERVER_AUDIT_FILE_PATH` | `/rdsdbdata/log/audit/` | `/rdsdbdata/log/audit/` | ログファイルの場所。ログファイルには、`SERVER_AUDIT_EVENTS` で指定されたアクティビティのレコードが含まれます。詳細については、「[データベースログファイルの表示とリスト化](USER_LogAccess.Procedural.Viewing.md)」および「[MariaDB データベースのログファイル](USER_LogAccess.Concepts.MariaDB.md)」を参照してください。 |
| `SERVER_AUDIT_FILE_ROTATE_SIZE` | 1-1000000000 | 1000000 | このバイト数のサイズに達するとファイルがローテーションします。詳細については、「[MariaDB のログのローテーションと保持](USER_LogAccess.MariaDB.LogFileSize.md)」を参照してください。 |
| `SERVER_AUDIT_FILE_ROTATIONS` | 0-100 | 9 | `server_audit_output_type=file` 時に保存するログローテーション数。0 に設定すると、ログファイルはローテーションされません。詳細については、[MariaDB のログのローテーションと保持](USER_LogAccess.MariaDB.LogFileSize.md)および[データベースログファイルのダウンロード](USER_LogAccess.Procedural.Downloading.md)を参照してください。 |
| `SERVER_AUDIT_EVENTS` | `CONNECT`, `QUERY`, `TABLE`, `QUERY_DDL`, `QUERY_DML`, `QUERY_DML_NO_SELECT`, `QUERY_DCL` | `CONNECT`, `QUERY` | ログに記録するアクティビティのタイプ。MariaDB 監査プラグインのインストール自体も記録されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.MariaDB.Options.html) |
| `SERVER_AUDIT_INCL_USERS` | 複数のカンマ区切り値 | なし | 指定されたユーザーからのアクティビティのみを含めます。デフォルトでは、アクティビティはすべてのユーザーについて記録されます。`SERVER_AUDIT_INCL_USERS` と `SERVER_AUDIT_EXCL_USERS` は相互に排他的です。`SERVER_AUDIT_INCL_USERS` に値を追加する場合は、`SERVER_AUDIT_EXCL_USERS` に追加される値がないことを確認してください。 |
| `SERVER_AUDIT_EXCL_USERS` | 複数のカンマ区切り値 | なし | 指定されたユーザーからのアクティビティを除外します。デフォルトでは、アクティビティはすべてのユーザーについて記録されます。`SERVER_AUDIT_INCL_USERS` と `SERVER_AUDIT_EXCL_USERS` は相互に排他的です。`SERVER_AUDIT_EXCL_USERS` に値を追加する場合は、`SERVER_AUDIT_INCL_USERS` に追加される値がないことを確認してください。 `rdsadmin` ユーザーは 1 秒ごとにデータベースをクエリしてデータベースのヘルスチェックを行います。そのほかの設定によっては、このアクティビティによってログファイルのサイズが急激に増大する可能性があります。このアクティビティを記録する必要がない場合は、`SERVER_AUDIT_EXCL_USERS`リストに`rdsadmin`ユーザーを追加します。 `CONNECT` アクティビティは、ユーザーがこのオプション設定で指定されていても、すべてのユーザーについて常に記録されます。 |
| `SERVER_AUDIT_LOGGING` | `ON` | `ON` | ログ記録がアクティブです。唯一の有効な値は `ON` です。Amazon RDS では、ログ記録の非アクティブ化はサポートしていません。ログ記録を非アクティブ化する場合は、MariaDB 監査プラグインを削除します。詳細については、「[MariaDB 監査プラグインの削除](#Appendix.MariaDB.Options.AuditPlugin.Remove)」を参照してください。 |
| `SERVER_AUDIT_QUERY_LOG_LIMIT` | 0-2147483647 | 1024 | レコードのクエリ文字列の長さに対する制限。 |
### MariaDB 監査プラグインの追加
MariaDB 監査プラグインを DB インスタンスに追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
MariaDB 監査プラグインを追加した後で、DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、直ちに監査が開始されます。
**MariaDB 監査プラグインを追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。それ以外の場合は、カスタム DB オプショングループを作成します。**[Engine]** (エンジン) で **[mariadb]** を選択し、**[Major engine version]** (メジャーエンジンバージョン) で **[10.3]** またはそれ以降を選択します。詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**MARIADB\$1AUDIT\$1PLUGIN**] オプションを追加し、オプションを設定します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。各設定の詳細については、「[監査プラグインのオプション設定](#Appendix.MariaDB.Options.AuditPlugin.Options)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、DB インスタンスを修正し、新しいオプショングループをアタッチすることで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### MariaDB 監査プラグインのログの表示とダウンロード
MariaDB 監査プラグインを有効にした後は、他のテキストベースのログファイルと同様の方法でログファイル内の結果にアクセスします。監査ログファイルは `/rdsdbdata/log/audit/` にあります。コンソールでログファイルを表示する方法の詳細については、「[データベースログファイルの表示とリスト化](USER_LogAccess.Procedural.Viewing.md)」を参照してください。ログファイルのダウンロードについては、「[データベースログファイルのダウンロード](USER_LogAccess.Procedural.Downloading.md)」を参照してください。
### MariaDB 監査プラグインの設定の変更
MariaDB 監査プラグインを有効にした後、プラグインの設定を変更できます。オプション設定の変更方法の詳細については、「[オプションの設定を変更する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption)」を参照してください。各設定の詳細については、「[監査プラグインのオプション設定](#Appendix.MariaDB.Options.AuditPlugin.Options)」を参照してください。
### MariaDB 監査プラグインの削除
Amazon RDS では、MariaDB 監査プラグインのログ記録の無効化はサポートされていません。ただし、DB インスタンスからプラグインを削除することはできます。MariaDB 監査プラグインを削除すると、DB インスタンスが自動的に再起動され、監査が停止します。
MariaDB 監査プラグインを DB インスタンスから削除するには、次のいずれかを実行します。
+ MariaDB 監査プラグインが所属するオプショングループからプラグインを削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、プラグインが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# MariaDB のパラメータ
デフォルトでは、MariaDB DB インスタンスは MariaDB データベースに固有の DB パラメータグループを使用します。このパラメータグループには、MySQL データベースエンジンの Amazon RDS DB パラメータグループに含まれるいくつかのパラメータがありますが、すべてのパラメータがあるわけではありません。また、いくつかの新しい MariaDB 固有のパラメータも含まれます。パラメータグループの操作とパラメータの設定については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
## MariaDB パラメータの表示
RDS for MariaDB パラメータは、選択したストレージエンジンのデフォルト値に設定されます。MariaDB パラメータの詳細については、[MariaDB のドキュメント](http://mariadb.com/kb/en/mariadb/documentation/)を参照してください。MariaDB ストレージエンジンの詳細については、「[Amazon RDS の MariaDB でサポートされているストレージエンジン](MariaDB.Concepts.Storage.md)」を参照してください。
特定の RDS for MariaDB バージョンで使用できるパラメータは、RDS コンソールまたは AWS CLI で確認できます。RDS コンソールでの MariaDB パラメータグループ内のパラメータの表示方法については、「[Amazon RDS のDB パラメータグループのパラメータ値の表示](USER_WorkingWithParamGroups.Viewing.md)」を参照してください。
AWS CLI を使用して [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html) コマンドを実行すると、RDS for MariaDB バージョンのパラメータを表示できます。`--db-parameter-group-family` オプションには、次の値のうち 1 つを指定します。
+ `mariadb11.8`
+ `mariadb11.4`
+ `mariadb10.11`
+ `mariadb10.6`
+ `mariadb10.5`
+ `mariadb10.4`
+ `mariadb10.3`
例えば、RDS for MariaDB バージョン 10.6 のパラメータを表示するには、次のコマンドを実行します。
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6
```
出力は次のようになります。
```
{
"EngineDefaults": {
"Parameters": [
{
"ParameterName": "alter_algorithm",
"Description": "Specify the alter table algorithm.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "string",
"AllowedValues": "DEFAULT,COPY,INPLACE,NOCOPY,INSTANT",
"IsModifiable": true
},
{
"ParameterName": "analyze_sample_percentage",
"Description": "Percentage of rows from the table ANALYZE TABLE will sample to collect table statistics.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "float",
"AllowedValues": "0-100",
"IsModifiable": true
},
{
"ParameterName": "aria_block_size",
"Description": "Block size to be used for Aria index pages.",
"Source": "engine-default",
"ApplyType": "static",
"DataType": "integer",
"AllowedValues": "1024-32768",
"IsModifiable": false
},
{
"ParameterName": "aria_checkpoint_interval",
"Description": "Interval in seconds between automatic checkpoints.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "integer",
"AllowedValues": "0-4294967295",
"IsModifiable": true
},
...
```
RDS for MariaDB バージョン 10.6 の変更可能なパラメータのみを一覧表示するには、次のコマンドを実行します。
Linux、macOS、Unix の場合:
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6 \
--query 'EngineDefaults.Parameters[?IsModifiable==`true`]'
```
Windows の場合:
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6 ^
--query "EngineDefaults.Parameters[?IsModifiable==`true`]"
```
## 使用できない MySQL パラメータ
以下の MySQL パラメータは、MariaDB 固有の DB パラメータグループでは使用できません。
+ bind\$1address
+ binlog\$1error\$1action
+ binlog\$1gtid\$1simple\$1recovery
+ binlog\$1max\$1flush\$1queue\$1time
+ binlog\$1order\$1commits
+ binlog\$1row\$1image
+ binlog\$1rows\$1query\$1log\$1events
+ binlogging\$1impossible\$1mode
+ block\$1encryption\$1mode
+ core\$1file
+ default\$1tmp\$1storage\$1engine
+ div\$1precision\$1increment
+ end\$1markers\$1in\$1json
+ enforce\$1gtid\$1consistency
+ eq\$1range\$1index\$1dive\$1limit
+ explicit\$1defaults\$1for\$1timestamp
+ gtid\$1executed
+ gtid-mode
+ gtid\$1next
+ gtid\$1owned
+ gtid\$1purged
+ log\$1bin\$1basename
+ log\$1bin\$1index
+ log\$1bin\$1use\$1v1\$1row\$1events
+ log\$1slow\$1admin\$1statements
+ log\$1slow\$1slave\$1statements
+ log\$1throttle\$1queries\$1not\$1using\$1indexes
+ master-info-repository
+ optimizer\$1trace
+ optimizer\$1trace\$1features
+ optimizer\$1trace\$1limit
+ optimizer\$1trace\$1max\$1mem\$1size
+ optimizer\$1trace\$1offset
+ relay\$1log\$1info\$1repository
+ rpl\$1stop\$1slave\$1timeout
+ slave\$1parallel\$1workers
+ slave\$1pending\$1jobs\$1size\$1max
+ slave\$1rows\$1search\$1algorithms
+ storage\$1engine
+ table\$1open\$1cache\$1instances
+ timed\$1mutexes
+ transaction\$1allow\$1batching
+ validate-password
+ validate\$1password\$1dictionary\$1file
+ validate\$1password\$1length
+ validate\$1password\$1mixed\$1case\$1count
+ validate\$1password\$1number\$1count
+ validate\$1password\$1policy
+ validate\$1password\$1special\$1char\$1count
MySQL パラメータの詳細については、[MySQL のドキュメント](https://dev.mysql.com/doc/refman/8.0/en/)を参照してください。
# MySQL DB スナップショットから MariaDB DB インスタンスへのデータ移行
AWS マネジメントコンソール、AWS CLI、または Amazon RDS API を使用して、RDS for MySQL DB スナップショットを MariaDB を実行している新しい DB インスタンスに移行できます。MySQL 5.6 か 5.7 を実行している Amazon RDS DB インスタンスから作成された DB スナップショットを使用する必要があります。RDS for MySQL DB スナップショットを作成する方法については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」を参照してください。
スナップショットの移行は、スナップショットを取得した元の DB インスタンスには影響しません。元の DB インスタンスの代わりとしてトラフィックを転送する前に、新しい DB インスタンスをテストして検証できます。
MySQL から MariaDB に移行した後、MariaDB DB インスタンスは、デフォルトの DB パラメータグループやオプショングループに関連付けられます。DB スナップショットを復元した後、新しい DB インスタンスにカスタム DB パラメータグループを関連付けることができます。ただし、MariaDB パラメータグループには異なる設定可能なシステム可変があります。MySQL と MariaDB のシステム可変の違いについては、「[MariaDB と MySQL のシステム可変の違い](https://mariadb.com/kb/en/system-variable-differences-between-mariadb-and-mysql/)」を参照してください。DB パラメータグループの詳細については、[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md) を参照してください。オプションのグループの詳細については、[オプショングループを使用する](USER_WorkingWithOptionGroups.md) を参照してください。
## 移行の実行
AWS マネジメントコンソール、AWS CLI、または RDS API を使用して、RDS for MySQL DBスナップショットを新しいMariaDB DBインスタンスに移行できます。
### コンソール
**MySQL DB スナップショットを MariaDB DB インスタンスに移行するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. ナビゲーションペインで、[**Snapshots**] を選択し、移行する MySQL DB スナップショットを選択します。
1. 「**アクション**」で「**スナップショットの移行**」 を選択します。「**Migrate Database**」 ページが表示されます。
1. [**Migrate to DB Engine**] で、[**mariadb**] を選択します。
Amazon RDS は** DB エンジンバージョン**を自動的に選択します。DB エンジンバージョンを変更することはできません。
![\[Amazon RDS コンソールの、MySQL から MariaDB に移行する [データベースの移行] ページ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDB.png)
1. 残りのセクションで、DB インスタンス設定を指定します。各設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」を参照してください。
1. **移行** を選択します。
### AWS CLI
MySQL DB スナップショットから MariaDB DB インスタンスにデータを移行するには、以下のオプションを指定して AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) コマンドを実行します。
+ --DB インスタンス識別子 - DB スナップショットから作成される DB インスタンスの名前。
+ --db-snapshot-identifier - リストア元の DB スナップショットの識別子。
+ --engine - 新しいインスタンスに使用するデータベースエンジン。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds restore-db-instance-from-db-snapshot \
2. --db-instance-identifier newmariadbinstance \
3. --db-snapshot-identifier mysqlsnapshot \
4. --engine mariadb
```
Windows の場合:
```
1. aws rds restore-db-instance-from-db-snapshot ^
2. --db-instance-identifier newmariadbinstance ^
3. --db-snapshot-identifier mysqlsnapshot ^
4. --engine mariadb
```
### API
MySQL DB スナップショットから MariaDB DB インスタンスにデータを移行するには、Amazon RDS API オペレーション [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) を呼び出します。
## MariaDB と MySQL の間の非互換性
MySQL と MariaDB の間の非互換性は以下のとおりです。
+ MySQL 8.0 で作成した DB スナップショットは MariaDB に移行できません。
+ ソース MySQL データベースで SHA256 パスワードハッシュを使用している場合、MariaDB データベースに接続する前に SHA256 でハッシュ化されたユーザーパスワードをリセットしてください。次のコードは、SHA256 でハッシュ化されたパスワードをリセットする方法を示しています。
```
SET old_passwords = 0;
UPDATE mysql.user SET plugin = 'mysql_native_password',
Password = PASSWORD('new_password')
WHERE (User, Host) = ('master_user_name', %);
FLUSH PRIVILEGES;
```
+ RDS マスターユーザーアカウントが SHA-256 パスワードハッシュを使用している場合、AWS マネジメントコンソール、[https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI コマンド、または [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API オペレーションを使用してパスワードをリセットしてください。DB インスタンスの変更については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
+ MariaDB では、Memcached プラグインはサポートされていません。ただし、Memcached プラグインで使用されるデータは InnoDB テーブルとして保存されます。MySQL DB スナップショットを移行した後、SQL を使用して Memcached プラグインで使用されるデータにアクセスできます。innodb\$1memcache データベースに関する詳細については、「[InnoDB memcached Plugin Internals](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-internals.html)」を参照してください。
# Amazon RDS SQL での MariaDB リファレンス
ここでは、MariaDB DB エンジンを実行する Amazon RDS インスタンスで使用できるシステムストアドプロシージャについて説明します。
MariaDB DB インスタンスと MySQL DB インスタンスに対して利用できるシステムストアドプロシージャを使用できます。これらのストアドプロシージャは、「[RDS for MySQL ストアドプロシージャリファレンス](Appendix.MySQL.SQLRef.md)」に記載されています。MariaDB DB インスタンスは、`mysql.rds_start_replication_until` と `mysql.rds_start_replication_until_gtid` を除くすべてのストアドプロシージャをサポートします。
さらに、次のシステムストアドプロシージャが、MariaDB を実行する Amazon RDS DB インスタンスでのみサポートされています。
+ [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md)
+ [mysql.rds\$1kill\$1query\$1id](mysql_rds_kill_query_id.md)
+ [mysql.rds\$1execute\$1operation](mysql_rds_execute_operation.md)
# mysql.rds\$1replica\$1status
MariaDB リードレプリカのレプリケーションステータスを表示します。
リードレプリカでこの手順を呼び出して、レプリカスレッドの基本パラメータに関するステータス情報を表示します。
## 構文
```
CALL mysql.rds_replica_status;
```
## 使用に関する注意事項
この手順は、MariaDB バージョン 10.5 以降を実行している MariaDB DB インスタンスのみでサポートされます。
この手順は、`SHOW REPLICA STATUS` コマンドと同等です。このコマンドは、MariaDB バージョン 10.5 以降の DB インスタンスではサポートされません。
MariaDB の以前のバージョンでは、同等の `SHOW SLAVE STATUS` コマンドには `REPLICATION SLAVE` 特権が必要でした。MariaDB バージョン 10.5 以上では、`REPLICATION REPLICA ADMIN` 権限が必要です。MariaDB 10.5 以上の DB インスタンスの RDS 管理を保護するために、この新しい権限は RDS マスターユーザーに付与されません。
## 例
次の例は、MariaDB リードレプリカのステータスを示しています。
```
call mysql.rds_replica_status;
```
応答は次の例のようになります。
```
*************************** 1. row ***************************
Replica_IO_State: Waiting for master to send event
Source_Host: XX.XX.XX.XXX
Source_User: rdsrepladmin
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin-changelog.003988
Read_Source_Log_Pos: 405
Relay_Log_File: relaylog.011024
Relay_Log_Pos: 657
Relay_Source_Log_File: mysql-bin-changelog.003988
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table: mysql.rds_sysinfo,mysql.rds_history,mysql.rds_replication_status
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 405
Relay_Log_Space: 1016
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: 0
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 807509301
Source_SSL_Crl:
Source_SSL_Crlpath:
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-807509301-3980
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: optimistic
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Replica_SQL_Running_State: Reading event from the relay log
Replica_DDL_Groups: 15
Replica_Non_Transactional_Groups: 0
Replica_Transactional_Groups: 3658
1 row in set (0.000 sec)
Query OK, 0 rows affected (0.000 sec)
```
# mysql.rds\$1set\$1external\$1master\$1gtid
Amazon RDS 外部で動作する MariaDB インスタンスから MariaDB DB インスタンスに対して、GTID ベースのレプリケーションを設定します。このストアドプロシージャは、外部の MariaDB インスタンスのバージョンが 10.0.24 以降である場合のみサポートされます。1 つまたは両方のインスタンスが MariaDB のグローバルトランザクション識別子 (GTID) をサポートしていない場合にレプリケーションを設定する際は、「[mysql.rds\$1set\$1external\$1master (RDS for MariaDB および RDS for MySQL メジャーバージョン 8.0 以前)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)」を使用します。
レプリケーションで GTID を使用すると、クラッシュのリスクがない安全性機能が実現されます。これはバイナリログのレプリケーションでは提供されません。したがって、レプリケーションのインスタンスがサポートしている場合は、GTID の使用を推奨します。
## 構文
```
CALL mysql.rds_set_external_master_gtid(
host_name
, host_port
, replication_user_name
, replication_user_password
, gtid
, ssl_encryption
);
```
## パラメータ
*host\$1name*
文字列。Amazon RDS の外部で動作する MariaDB インスタンス (ソースインスタンス) のホスト名または IP アドレス。
*host\$1port*
整数。Amazon RDS の外部で動作する MariaDB インスタンス (ソースインスタンス) で使用されるポート。ポート番号を変換する SSH ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって公開されるポート番号を指定します。
*replication\$1user\$1name*
文字列。リードレプリカとして設定される MariaDB DB インスタンスでの `REPLICATION SLAVE` アクセス許可を持つユーザーの ID。
*replication\$1user\$1password*
文字列。`replication_user_name` で指定されたユーザー ID のパスワード。
*gtid*
文字列。レプリケーションが開始されるソースインスタンスのグローバルトランザクション ID。
レプリケーションの設定中にソースインスタンスがロックされている場合は、`@@gtid_current_pos` を使用して現在の GTID を入手できます。したがって、GTID の取得時とレプリケーションの開始時点の間では、バイナリログは変更されません。
それ以外の場合、`mysqldump` のバージョン 10.0.13 以降を使用しているか、レプリケーションを開始する前にレプリカインスタンスを入力している場合は、`--master-data` オプションまたは `--dump-slave` オプションを使用して、出力の GTID の場所を取得できます。`mysqldump` のバージョン 10.0.13 以降を使用していない場合は、`SHOW MASTER STATUS` を実行するか、または同じ `mysqldump` オプションを使用してバイナリログファイル名と場所を取得できます。次に外部 MariaDB インスタンスで `BINLOG_GTID_POS` を実行して、それを GTID に変換します。
```
SELECT BINLOG_GTID_POS('', );
```
GTID の MariaDB 実装の詳細については、MariaDB ドキュメントの「[グローバルトランザクション ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/)」を参照してください。
*ssl\$1encryption*
レプリケーション接続で Secure Socket Layer (SSL) 暗号化を使用するかどうかを指定する値。1 は SSL 暗号化を使用することを指定し、0 は暗号化を使用しないことを指定します。デフォルトは 0 です。
`MASTER_SSL_VERIFY_SERVER_CERT` オプションはサポートされていません。このオプションは 0 に設定されます。つまり、接続は暗号化されますが、証明書は検証されません。
## 使用に関する注意事項
`mysql.rds_set_external_master_gtid` プロシージャは、マスターユーザーが実行してください。Amazon RDS の外部で動作する MariaDB インスタンスのレプリカとして設定される、MariaDB DB インスタンスで実行する必要があります。`mysql.rds_set_external_master_gtid` を実行する前に、Amazon RDS の外部で動作する MariaDB インスタンスをソースインスタンスとして必ず設定してください。詳細については、「[Amazon RDS for MariaDB DB インスタンスへのデータのインポート](MariaDB.Procedural.Importing.md)」を参照してください。
**警告**
2 つの Amazon RDS DB インスタンス間でレプリケーションを管理するために `mysql.rds_set_external_master_gtid` を使用しないでください。このストアドプロシージャは、RDS の外部で動作する 1 つの MariaDB インスタンスでレプリケーションする場合にのみ使用します。Amazon RDS DB インスタンス間でのレプリケーションの管理の詳細については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
`mysql.rds_set_external_master_gtid` を呼び出し、Amazon RDS DB インスタンスをリードレプリカとして設定した後で、レプリカで [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) を呼び出してレプリケーションプロセスを開始できます。[mysql.rds\$1reset\$1external\$1master (RDS for MariaDB および RDS for MySQL メジャーバージョン 8.0 以前)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) を呼び出して、リードレプリカの設定を削除することもできます。
`mysql.rds_set_external_master_gtid` が呼び出されると、Amazon RDS では、時刻、ユーザー、"マスターの設定" アクションが `mysql.rds_history` テーブルと `mysql.rds_replication_status` テーブルに記録されます。
## 例
MariaDB DB インスタンスで動作させる場合は、次の例にあるように、Amazon RDS の外部で動作する MariaDB のインスタンスのレプリカとして設定します。
```
call mysql.rds_set_external_master_gtid ('Sourcedb.some.com',3306,'ReplicationUser','SomePassW0rd','0-123-456',0);
```
# mysql.rds\$1kill\$1query\$1id
MariaDB サーバーに対して実行されているクエリを終了して、長時間実行されているクエリや問題のあるクエリを終了します。クエリ ID を識別し、特定のクエリを効果的に停止して、パフォーマンスの問題に対処し、最適なデータベースオペレーションを維持できます。
## 構文
```
CALL mysql.rds_kill_query_id(queryID);
```
## パラメータ
*queryID*
整数。終了するクエリの識別子。
## 使用に関する注意事項
MariaDB サーバーに対して実行中のクエリを停止するには、`mysql.rds_kill_query_id` プロシージャを使用して、そのクエリの ID を渡します。クエリ ID を取得するには、次に示すように、MariaDB の [情報スキーマ PROCESSLIST テーブル](http://mariadb.com/kb/en/mariadb/information-schema-processlist-table/)を参照します。
```
SELECT USER, HOST, COMMAND, TIME, STATE, INFO, QUERY_ID FROM
INFORMATION_SCHEMA.PROCESSLIST WHERE USER = '';
```
MariaDB サーバーへの接続は保持されます。
## 例
次の例では、230040 のクエリ ID を持つクエリを終了します。
```
call mysql.rds_kill_query_id(230040);
```
# mysql.rds\$1execute\$1operation
InnoDB オペレーションを実行して、バッファプールの状態と一時テーブルスペースを管理します。この手順を使用して、バッファプールの状態のダンプとロード、一時テーブルスペースの切り捨てなどの InnoDB オペレーションを動的に制御できます。
## 構文
```
CALL mysql.rds_execute_operation(operation);
```
## パラメータ
*オペレーション*
文字列。実行する InnoDB オペレーション。次の値を指定できます。
+ *innodb\$1buffer\$1pool\$1dump\$1now* – バッファプールの現在の状態をダンプするオペレーション。
+ *innodb\$1buffer\$1pool\$1load\$1now* – 保存されたバッファプールの状態をロードするオペレーション。
+ *innodb\$1buffer\$1pool\$1load\$1abort* – バッファプールのロードオペレーションを中止するオペレーション。
+ *innodb\$1truncate\$1temporary\$1tablespace\$1now* – 一時テーブルスペースを切り捨てるオペレーション。
## 使用に関する注意事項
この手順は、MariaDB バージョン 11.8 以降を実行している MariaDB DB インスタンスのみでサポートされます。
実行中、バイナリログ記録は、これらの管理コマンドのレプリケーションを防ぐために一時的に無効になります。
この手順では、[https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/securing-connections-for-client-and-server#requiring-tls](https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/securing-connections-for-client-and-server#requiring-tls) テーブル内のすべてのオペレーションをログに記録することで監査証跡を維持します。
## 例
次の例は、`mysql.rds_execute_operation` を使用した一時的なテーブルスペースの縮小を示しています。
現在の一時テーブルスペースのサイズを確認するには、次のクエリを実行します。
```
SELECT FILE_SIZE FROM information_schema.innodb_sys_tablespaces WHERE name LIKE 'innodb_temporary';
+------------+
| FILE_SIZE |
+------------+
| 6723469312 | -- 6.3 GB
+------------+
```
一時テーブルを削除しても、グローバルテーブルスペースのストレージ使用量は減りません。グローバルテーブルスペースのサイズを減らすには、`mysql.rds_execute_operation` コマンドを実行して一時テーブルスペースを縮小します。
```
CALL mysql.rds_execute_operation('innodb_truncate_temporary_tablespace_now');
Query OK, 2 rows affected (0.004 sec)
```
手順を実行したら、スペースが再利用されたことを確認します。
```
SELECT FILE_SIZE FROM information_schema.innodb_sys_tablespaces WHERE name LIKE 'innodb_temporary';
+-----------+
| FILE_SIZE |
+-----------+
| 12582912 | -- 12 MB
+-----------+
```
**注記**
一時テーブルスペースのサイズと現在のワークロードによっては、縮小オペレーションに時間がかかる場合があります。
**重要**
一時テーブルスペースは、そのサイズに寄与したすべての一時テーブルが使用されなくなった場合にのみ縮小されます。インスタンスにアクティブな一時テーブルスペースがない場合は、この手順を実行することをお勧めします。
# MariaDB DB インスタンスのローカルタイムゾーン
デフォルトでは、MariaDB DB インスタンスのタイムゾーンは協定世界時 (UTC) です。代わりに、DB インスタンスのタイムゾーンをアプリケーションのローカルタイムゾーンに設定できます。
DB インスタンスのローカルタイムゾーンを設定するには、DB インスタンスのパラメータグループの `time_zone` パラメータを、このセクションで後述するサポートされている値のいずれかに設定します。パラメータグループの `time_zone` パラメータを設定すると、そのパラメータグループを使用しているすべての DB インスタンスとリードレプリカは、新しいローカルタイムゾーンを使用するように変更されます。パラメータグループのパラメータの設定については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
ローカルタイムゾーンを設定した後、データベースへのすべての新しい接続にその変更が反映されます。ローカルタイムゾーンを変更するときにデータベースへの接続を開いている場合、その接続を閉じて新しい接続を開くまで、ローカルタイムゾーンは更新されません。
DB インスタンスとそのリードレプリカには異なるローカルタイムゾーンを設定できます。そのためには、DB インスタンスとレプリカに異なるパラメータグループを使用し、各パラメータグループの `time_zone` パラメータを異なるローカルタイムゾーンに設定します。
AWS リージョン 間のレプリケーションを実行する場合は、ソース DB インスタンスとリードレプリカに異なるパラメータグループ (パラメータグループは AWS リージョン に固有のもの) を使用します。各インスタンスに同じローカルタイムゾーンを使用するには、インスタンスとリードレプリカのパラメータグループの `time_zone` パラメータを設定する必要があります。
DB スナップショットから DB インスタンスを復元すると、ローカルタイムゾーンが UTC に設定されます。復元が完了したら、タイムゾーンをローカルタイムゾーンに更新できます。DB インスタンスをある時点まで復元する場合、復元された DB インスタンスのローカルタイムゾーンは、復元された DB インスタンスのパラメータグループに設定されているタイムゾーンです。
Internet Assigned Numbers Authority (IANA) は年に数回、[https://www.iana.org/time-zones](https://www.iana.org/time-zones) で新しいタイムゾーンを公開します。RDS が MariaDB の新しいマイナーメンテナンスリリースをリリースするたびに、リリース時の最新のタイムゾーンデータが同梱されます。MariaDB の最新バージョンの RDS を使用すると、RDS からの最新のタイムゾーンデータが得られます。DB インスタンスに最新のタイムゾーンデータがあることを確認するには、DB エンジンの上位バージョンにアップグレードすることをお勧めします。または、MariaDB DB インスタンスのタイムゾーンテーブルを手動で変更することもできます。そのためには、SQL コマンドを使用するか、SQL クライアントで [mysql\$1tzinfo\$1to\$1sql ツール](https://mariadb.com/kb/en/mysql_tzinfo_to_sql/)を実行します。タイムゾーンデータを手動で更新して、DB インスタンスを再起動し、変更を有効にします。RDS は、実行中の DB インスタンスのタイムゾーンデータを変更またはリセットしません。新しいタイムゾーンデータは、データベースエンジンのバージョンアップグレードを実行する場合にのみインストールされます。
ローカルタイムゾーンは以下のいずれかの値に設定できます。
| ゾーン | タイムゾーン |
| --- | --- |
| アフリカ | Africa/Cairo、Africa/Casablanca、Africa/Harare、Africa/Monrovia、Africa/Nairobi、Africa/Tripoli、Africa/Windhoek |
| 南北アメリカ大陸 | America/Araguaina、America/Asuncion、America/Bogota、America/Buenos\$1Aires、America/Caracas、America/Chihuahua、America/Cuiaba、America/Denver、America/Fortaleza、America/Guatemala、America/Halifax、America/Manaus、America/Matamoros、America/Monterrey、America/Montevideo、America/Phoenix、America/Santiago、America/Tijuana |
| アジア | Asia/Amman、Asia/Ashgabat、Asia/Baghdad、Asia/Baku、Asia/Bangkok、Asia/Beirut、Asia/Calcutta、Asia/Damascus、Asia/Dhaka、Asia/Irkutsk、Asia/Jerusalem、Asia/Kabul、Asia/Karachi、Asia/Kathmandu、Asia/Krasnoyarsk、Asia/Magadan、Asia/Muscat、Asia/Novosibirsk、Asia/Riyadh、Asia/Seoul、Asia/Shanghai、Asia/Singapore、Asia/Taipei、Asia/Tehran、Asia/Tokyo、Asia/Ulaanbaatar、Asia/Vladivostok、Asia/Yakutsk、Asia/Yerevan |
| 大西洋 | Atlantic/Azores |
| オーストラリア | Australia/Adelaide、Australia/Brisbane、Australia/Darwin、Australia/Hobart、Australia/Perth、Australia/Sydney |
| ブラジル | Brazil/DeNoronha、Brazil/East |
| カナダ | Canada/Newfoundland, Canada/Saskatchewan, Canada/Yukon |
| 欧州 | Europe/Amsterdam、Europe/Athens、Europe/Dublin、Europe/Helsinki、Europe/Istanbul、Europe/Kaliningrad Europe/Moscow、Europe/Paris、Europe/Prague、Europe/Sarajevo |
| 太平洋 | Pacific/Auckland、Pacific/Fiji、Pacific/Guam、Pacific/Honolulu、Pacific/Samoa |
| 米国 | US/Alaska、US/Central、US/East-Indiana、US/Eastern、US/Pacific |
| UTC | UTC |
# Amazon RDS for MySQL の既知の問題と制限
RDS for MariaDB を使用する際の既知の問題と制限事項は次のとおりです。
**注記**
これはすべてを網羅したリストではありません。
**Topics**
+ [Amazon RDS での MariaDB のファイルサイズ制限](#RDS_Limits.FileSize.MariaDB)
+ [InnoDB 予約語](#MariaDB.Concepts.InnodbDatabaseName)
+ [カスタムポート](#MariaDB.Concepts.CustomPorts)
+ [Performance Insights](#MariaDB.Concepts.PerformanceInsights)
## Amazon RDS での MariaDB のファイルサイズ制限
MariaDB DB インスタンスの場合、InnoDB file-per-table テーブルスペースを使用するとき、テーブルのサイズは最大 16 TB です。また、システムのテーブルスペースも最大 16 TB に制限されています。InnoDB file-per-table テーブルスペース (各テーブルが独自のテーブルスペースに存在) が、デフォルトで MariaDB DB インスタンスに設定されます。この制限は MariaDB DB インスタンスの最大ストレージ制限とは関係ありません。ストレージの制限の詳細については、「[Amazon RDS DB インスタンスストレージ](CHAP_Storage.md)」を参照してください。
InnoDB file-per-table テーブルスペースの使用は、アプリケーションにより長所と短所があります。アプリケーションに最適な方法を判断するには、MySQL ドキュメントの「[File-Per-Table テーブルスペース](https://dev.mysql.com/doc/refman/5.7/en/innodb-file-per-table-tablespaces.html)」を参照してください。
テーブルを最大ファイルサイズまで拡張可能にすることはお勧めしません。一般的に望ましいのは、データを小さなテーブルにパーティショニングすることです。これにより、パフォーマンスと復旧時間が改善される可能性があります。
大きなテーブルを小さなテーブルに分ける方法の 1 つはパーティション化です。*パーティション化*では、指定したルールに基づいて、大きなテーブルの各部分を個別のファイルに分散します。例えば、トランザクションを日付ごとに保存する場合、パーティション化を使用して古いトランザクションを別々のファイルに分散させるパーティションルールを作成できます。また、定期的に、アプリケーションですぐに使用する必要のない履歴トランザクションデータをアーカイブできます。詳細については、MySQL ドキュメントの「[Partitioning](https://dev.mysql.com/doc/refman/5.7/en/partitioning.html)」を参照してください。
**すべての InnoDB テーブルスペースのサイズを確認するには**
+ 次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルがあるか判断します。
**注記**
MariaDB 10.6 以降では、このクエリは InnoDB システムテーブルスペースのサイズも返します。
10.6 より前のバージョンの MariaDB では、システムテーブルをクエリして InnoDB システムテーブルスペースのサイズを判断することはできません。新しいバージョンにアップグレードすることをお勧めします。
```
1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2)
2. as "Tablespace Size (GB)"
3. FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC;
```
**InnoDB 以外のユーザーテーブルのサイズを確認するには**
+ 次の SQL コマンドを使用して、InnoDB 以外のユーザーテーブルが過度に大きいかどうかを確認します。
```
SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE)
/ 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')
and ENGINE<>'InnoDB';
```
**InnoDB file-per-table テーブルスペースを有効にするには**
+ DB インスタンスのパラメータグループの `innodb_file_per_table` パラメータを `1` に設定します。
**InnoDB file-per-table テーブルスペースを無効にするには**
+ DB インスタンスのパラメータグループの `innodb_file_per_table` パラメータを `0` に設定します。
パラメータグループの更新については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
InnoDB file-per-table テーブルスペースを有効または無効にした場合は、`ALTER TABLE` コマンドを発行できます。このコマンドを使用して、テーブルをグローバルテーブルスペースからテーブル独自のテーブルスペースに移動できます。または、テーブルを独自のテーブルスペースからグローバルテーブルスペースに移動できます。次に例を示します。
```
1. ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=COPY;
```
## InnoDB 予約語
`InnoDB` は MariaDB の RDS の予約語です。MariaDB データベースにこの名前を使用することはできません。
## カスタムポート
Amazon RDS は MariaDB エンジンのカスタムポート 33060 への接続をブロックします。MariaDB エンジン用に別のポートを選択してください。
## Performance Insights
InnoDB カウンターは、MariaDB コミュニティではサポートされなくなったため、MariaDB バージョン 10.11 の RDS の Performance Insights には表示されません。