のソースとしての My SQL互換データベースの使用 AWS DMS - AWS データベース移行サービス
マイSQLからマイSQLへの移行ソースとしての SQLの使用セルフマネージド My SQLをソースとして使用するマネージド My AWS SQL をソースとして使用するソースとしての MySQL の制限XA トランザクションのサポートエンドポイント設定My のソースデータ型SQL

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

のソースとしての My SQL互換データベースの使用 AWS DMS

AWS Database Migration Service を使用して、My SQL互換データベース (MySQL、MariaDB、または Amazon Aurora MySQL) からデータを移行できます。

がソースとして AWS DMS サポートする MySQL のバージョンについては、「」を参照してくださいのソース AWS DMS。

を使用してSSL、My SQL互換エンドポイントとレプリケーションインスタンス間の接続を暗号化できます。My 互換エンドポイントSSLで を使用する方法の詳細については、SQL「」を参照してくださいSSL で を使用する AWS Database Migration Service。

以下のセクションでは、「セルフマネージド」という用語は、オンプレミスまたは Amazon にインストールされているすべてのデータベースに適用されますEC2。AWS「 マネージド」という用語は、Amazon RDS、Amazon Aurora、または Amazon S3 のすべてのデータベースに適用されます。

My SQL互換データベースと の操作の詳細については AWS DMS、以下のセクションを参照してください。

を使用して SQLから SQLに移行する AWS DMS

My 以外のデータベースエンジンから MySQL SQL データベースに移行する異種移行の場合、 AWS DMS はほとんどの場合、最適な移行ツールです。ただし、マイSQLデータベースからマイSQLデータベースに移行する同種移行の場合は、同種データ移行プロジェクトを使用することをお勧めします。 同種データ移行では、ネイティブデータベースツールを使用して、 と比較してデータ移行のパフォーマンスと精度が向上します AWS DMS。

のソースとしての My SQL互換データベースの使用 AWS DMS

のソースとして MySQL データベースの使用を開始する前に AWS DMS、次の前提条件を満たしていることを確認してください。これらの前提条件は、セルフマネージド型ソースまたは AWSマネージド型ソースに適用されます。

レプリケーション管理者ロール AWS DMS を持つ のアカウントが必要です。ロールには、次の権限が必要です。

  • REPLICATION CLIENT – この権限はCDCタスクにのみ必要です。つまり、 full-load-onlyタスクにはこの権限は必要ありません。

  • REPLICATION SLAVE – この権限はCDCタスクにのみ必要です。つまり、 full-load-onlyタスクにはこの権限は必要ありません。

  • SUPER – この権限は、 5.6.6 より前のバージョンの SQLでのみ必要です。

AWS DMS ユーザーは、レプリケーション用に指定されたソーステーブルに対するSELECT権限も持っている必要があります。

マイSQL固有の移行前評価を使用する場合は、次の権限を付与します。

grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher

のソースとしてのセルフマネージド型 My SQL互換データベースの使用 AWS DMS

次のセルフマネージド型 My SQL互換データベースを のソースとして使用できます AWS DMS。

  • マイSQLコミュニティエディション

  • StandardSQL Edition

  • EnterpriseSQL Edition

  • MySQL Cluster キャリアグレードエディション

  • MariaDB Community Edition

  • MariaDB Enterprise Edition

  • MariaDB Column Store

を使用するにはCDC、バイナリログ記録を必ず有効にしてください。バイナリログ記録を有効にするには、My の my.ini (Windows) SQLまたは my.cnf (UNIX) ファイルで次のパラメータを設定する必要があります。

パラメータ

値

server_id

このパラメータは、1 以上の値に設定します。

log-bin

パスをバイナリログファイル (log-bin=E:\MySql_Logs\BinLog) に設定します。ファイル拡張子を含めないでください。

binlog_format

このパラメータは ROW に設定します。binlog_format が STATEMENT に設定されているときは場合によっては、ターゲットにデータレプリケーション時に矛盾が生じる可能性があるため、レプリケーション中にこの設定をお勧めします。データベースエンジンは、binlog_format が MIXED に設定されているとき、類似の矛盾したデータもターゲットに書き込みます。これはデータベースエンジンが自動的にSTATEMENTベースのログに切り替わり、ターゲットデータベースに一貫性のないデータが書き込まれることがあるためです。

expire_logs_days

このパラメータは、1 以上の値に設定します。ディスク容量の使いすぎを防ぐため、デフォルト値の 0 は使用しないことをお勧めします。

binlog_checksum

DMS バージョン 3.4.7 以前NONEでは、このパラメータを に設定します。

binlog_row_image

このパラメータは FULL に設定します。

log_slave_updates

MySQL または MariaDB のリードレプリカをソースとして使用TRUEしている場合は、このパラメータを に設定します。

既存のデータを移行し、継続的な変更モードをレプリケートするDMS移行タスクのソースとして MySQL または MariaDB リードレプリカを使用している場合、データが失われる可能性があります。 DMSは、全ロード中または次の条件CDCの下でトランザクションを書き込むことはありません。

  • トランザクションは、DMSタスクの開始前にプライマリインスタンスにコミットされました。

  • プライマリインスタンスとレプリカ間の遅延により、トランザクションはDMSタスクが開始されるまでレプリカにコミットされませんでした。

プライマリインスタンスとレプリカ間の遅延が長いほど、データ損失の可能性が大きくなります。

ソースが NDB (クラスター化された) データベースエンジンを使用している場合は、そのストレージエンジンを使用するテーブルCDCで を有効にするように次のパラメータを設定する必要があります。これらの変更を My SQLの my.ini (Windows) または my.cnf (UNIX) ファイルに追加します。

パラメータ

値

ndb_log_bin

このパラメータは ON に設定します。この値により、クラスター化されたテーブルでの変更が確実にバイナリログに記録されます。

ndb_log_update_as_write

このパラメータは OFF に設定します。この値は、バイナリログにUPDATEステートメントとしてINSERTステートメントを書き込むのを防ぎます。

ndb_log_updated_only

このパラメータは OFF に設定します。この値に設定すると、バイナリログに変更された列だけでなく行全体が含められます。

のソースとしての AWSマネージド My SQL互換データベースの使用 AWS DMS

のソースとして、以下の AWS管理された My SQL互換データベースを使用できます AWS DMS。

  • マイSQLコミュニティエディション

  • MariaDB Community Edition

  • Amazon Aurora MySQL-Compatible Edition

のソースとして 管理 AWSの My SQL互換データベースを使用する場合は AWS DMS、 に次の前提条件があることを確認してくださいCDC。

  • RDS for MySQL と RDS for MariaDB のバイナリログを有効にするには、インスタンスレベルで自動バックアップを有効にします。Aurora MySQL クラスターのバイナリログを有効にするには、パラメータグループの binlog_format 変数を変更します。

    自動バックアップの設定の詳細については、「Amazon RDSユーザーガイド」の「自動バックアップの使用」を参照してください。

    Amazon RDS for MySQL データベースのバイナリログ記録の設定の詳細については、「Amazon RDSユーザーガイド」の「バイナリログ記録形式の設定」を参照してください。

    Aurora MySQL クラスターのバイナリログ記録の設定の詳細については、「Amazon Aurora MySQL クラスターのバイナリログ記録を有効にするにはどうすればよいですか？」を参照してください。

  • を使用する予定がある場合はCDC、バイナリログ記録を有効にします。Amazon RDS for MySQL データベースのバイナリログ記録の設定の詳細については、「Amazon RDSユーザーガイド」の「バイナリログ記録形式の設定」を参照してください。

  • バイナリログが使用可能であることを確認します AWS DMS。マネージド AWS型 My SQL互換データベースはバイナリログをできるだけ早く消去するため、ログが利用可能なままである時間を増やす必要があります。たとえば、ログ保持を 24 時間に伸ばすには、次のコマンドを実行します。

    
 call mysql.rds_set_configuration('binlog retention hours', 24);

  • binlog_format パラメータを "ROW" に設定します。

    注記

    MySQL または MariaDB では、 binlog_formatは動的パラメータであるため、新しい値を有効にするために再起動する必要はありません。ただし、新しい値は新しいセッションにのみ適用されます。レプリケーションの目的で binlog_format を ROW に切り替えても、値を変更する前にセッションが開始されていれば、データベースは引き続き MIXED 形式を使用して続くバイナリログを作成できます。これにより、 AWS DMS がソースデータベースのすべての変更を適切にキャプチャできなくなる場合があります。MariaDB または MySQL データベースの binlog_format設定を変更する場合は、データベースを再起動して既存のセッションをすべて閉じるか、 DML (データ操作言語) オペレーションを実行するアプリケーションを再起動してください。binlog_format パラメータを に変更した後、データベースがすべてのセッションを再起動するように強制ROWすると、データベースが後続のすべてのソースデータベースの変更を正しい形式で書き込み、 がそれらの変更を適切にキャプチャ AWS DMS できるようになります。

  • binlog_row_image パラメータを "Full" に設定します。

  • DMS バージョン 3.4.7 以前"NONE"では、 binlog_checksumパラメータを に設定します。Amazon RDS My でパラメータを設定する方法の詳細についてはSQL、「Amazon RDS ユーザーガイド」の「自動バックアップの使用」を参照してください。

  • Amazon RDS MySQL または Amazon RDS MariaDB リードレプリカをソースとして使用している場合は、リードレプリカでバックアップを有効にし、 log_slave_updatesパラメータが に設定されていることを確認しますTRUE。

のソースとして MySQL データベースを使用する場合の制限 AWS DMS

MySQL データベースをソースとして使用する場合は、次の点を考慮してください。

  • 変更データキャプチャ (CDC) は、Amazon RDS MySQL 5.5 以前ではサポートされていません。Amazon RDS My ではSQL、 を有効にするには、バージョン 5.6、5.7、または 8.0 を使用する必要がありますCDC。 CDCはセルフマネージド My SQL5.5 ソースでサポートされています。

  • CDC、、ADD COLUMN、および ではCREATE TABLE、列データ型DROP COLUMNの変更、および renaming a columnがサポートされています。ただし、DROP TABLE、RENAME TABLE、およびカラムのデフォルト値、カラムのNULL可能性、文字セットなどの他の属性に対する更新はサポートされていません。

  • ソースのパーティションテーブルの場合、ターゲットテーブルの準備モードをターゲットのテーブルの削除に設定すると、 SQLはターゲットにパーティションなしでシンプルなテーブル AWS DMS を作成します。パーティション分割されたテーブルをターゲットのパーティション分割されたテーブルに移行するには、ターゲットSQL My データベースでパーティション分割されたテーブルを事前に作成します。

  • ALTER TABLE table_name ADD COLUMN column_name ステートメントを使用してテーブルの先頭 (FIRST) または中間 (AFTER) に列を追加することはサポートされていません。列は常にテーブルの末尾に追加されます。

  • CDC テーブル名に大文字と小文字が含まれていて、ソースエンジンが大文字と小文字を区別しないファイル名のオペレーティングシステムでホストされている場合、 はサポートされません。たとえば、Microsoft Windows または OS X で HFS+ を使用します。

  • Aurora MySQL-Compatible Edition Serverless v1 は全ロードに使用できますが、 には使用できませんCDC。これは、My の前提条件を有効にすることができないためですSQL。詳細については、「パラメータグループと Aurora サーバーレス v1」をご参照ください。

    Aurora MySQL-Compatible Edition Serverless v2 は をサポートしていますCDC。

  • 列の AUTO_INCREMENT 属性は、ターゲットデータベース列に移行されません。

  • バイナリログが標準のブロックストレージに保存されている場合の変更のキャプチャはサポートされていません。例えば、バイナリログが Amazon S3 に保存されている場合、 は機能CDCしません。

  • AWS DMS は、デフォルトで InnoDB ストレージエンジンを使用してターゲットテーブルを作成します。InnoDB 以外のストレージエンジンを使用する必要がある場合、テーブルを手動で作成し、何もしないモードを使用してそのテーブルに移行する必要があります。

  • DMS 移行タスクモードが既存のデータの移行 - 全ロードのみである AWS DMS 場合を除き、Aurora MySQL レプリカを のソースとして使用することはできません。

  • 全ロード中に My SQL互換ソースが停止した場合、 AWS DMS タスクは エラーで停止しません。タスクは正常に終了しますが、ターゲットとソースが同期しない可能性があります。この場合、タスクを再開するか、影響を受けたテーブルを再ロードしてください。

  • 列の値の一部で作成されたインデックスは移行されません。たとえば、インデックス CREATE INDEX first_ten_chars ON customer (name(10)) はターゲットに作成されません。

  • 場合によっては、タスクがレプリケートされないように設定されています LOBs (SupportLobs「」はタスク設定で false であるか、タスクコンソールでLOB列を含めないが選択されています）。このような場合、 AWS DMS は MEDIUMBLOB、、LONGBLOB、MEDIUMTEXTおよび LONGTEXT列をターゲットに移行しません。

    BLOB、TINYBLOB、TEXT、および TINYTEXT列は影響を受けず、ターゲットに移行されます。

  • 一時データテーブルまたはシステムでバージョン管理されたテーブルは、MariaDB ソースおよびターゲットデータベースではサポートされていません。

  • 2 つの Amazon RDS Aurora MySQL クラスター間で移行する場合、RDSAurora MySQL ソースエンドポイントはレプリカインスタンスではなく、読み取り/書き込みインスタンスである必要があります。

  • AWS DMS は現在、MariaDB のビューの移行をサポートしていません。

  • AWS DMS では、My のパーティションテーブルDDLの変更はサポートされていませんSQL。中のパーティションDDL変更のテーブル停止をスキップするにはCDC、 skipTableSuspensionForPartitionDdlを に設定しますtrue。

  • AWS DMS は、バージョン 3.5.0 以降の XA トランザクションのみをサポートします。以前のバージョンは XA transactions をサポートしていません。 AWS DMS MariaDB バージョン 10.6 以降の XA トランザクションはサポートしていません。詳細については、XA トランザクションのサポート以下を参照してください。

  • AWS DMS ソースデータに含まれている場合でも、 はレプリケーションGTIDsに を使用しません。

  • AWS DMS は Aurora MySQL 拡張バイナリログをサポートしていません。

  • AWS DMS はバイナリログトランザクション圧縮をサポートしていません。

  • AWS DMS は、InnoDB ストレージエンジンを使用してデータベースSQLの ON イベントDELETECASCADEと ON UPDATECASCADEイベントを伝達しません。 InnoDB これらのイベントの場合、MySQL は子テーブルのカスケードされたオペレーションを反映するバイナリログイベントを生成しません。したがって、 AWS DMS は対応する変更を子テーブルにレプリケートできません。詳細については、「インデックス、外部キー、カスケード更新、または削除が移行されない」を参照してください。

  • AWS DMS は、計算された (VIRTUAL および GENERATED ALWAYS) 列の変更をキャプチャしません。この制限を回避するには、次の手順を実行します。

    • ターゲットデータベースにターゲットテーブルを事前に作成して、DO_NOTHINGまたは TRUNCATE_BEFORE_LOAD のフルロード設定の AWS DMS タスク設定を使用してタスクを作成する。

    • 計算列をタスクスコープから削除する変換ルールを追加する。変換ルールの詳細については、「 変換ルールおよび変換アクション」を参照。

XA トランザクションのサポート

Extended Architecture (XA) トランザクションは、複数のトランザクションリソースによる操作セットを単一の信頼性の高いグローバルトランザクションにグループ化するために使用できるトランザクションです。XA トランザクションは 2 フェーズコミットプロトコルを使用します。通常、XA トランザクションがオープンである間に変更をキャプチャすると、データが損失する可能性があります。データベースが XA トランザクションを使用していない場合は、IgnoreOpenXaTransactionsCheck のデフォルト値 TRUE を使用してこのアクセス権限と設定を無視できます。XA トランザクションのあるソースからレプリケーションを開始するには、次を実行します。

  • AWS DMS エンドポイントユーザーに次のアクセス許可があることを確認します。

    grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';

  • エンドポイント設定 IgnoreOpenXaTransactionsCheck を false に設定する。

注記

AWS DMS は、MariaDB ソース DB バージョン 10.6 以降の XA トランザクションをサポートしていません。

のソースとして MySQL を使用する場合のエンドポイント設定 AWS DMS

エンドポイント設定を使用して、追加の接続属性の使用と同様に、ソースSQLデータベースを設定できます。 AWS DMS コンソールを使用するか、 の create-endpoint コマンドを使用してAWS CLI、 --my-sql-settings '{"EndpointSetting": "value", ...}'JSON構文でソースエンドポイントを作成するときに設定を指定します。

次の表は、ソースとして MySQL で使用できるエンドポイント設定を示しています。

名前 説明
EventsPollInterval

データベースがアイドル状態のとき、バイナリログで新しい変更/イベントをチェックする頻度を指定します。

デフォルト値: 5

有効な値: 1～60

例: --my-sql-settings '{"EventsPollInterval": 5}'

この例では、 はバイナリログの変更を 5 秒ごとに AWS DMS チェックします。
ExecuteTimeout

AWS DMS バージョン 3.4.7 以降では、 SQLはソースエンドポイントのクライアントステートメントのタイムアウトを秒単位で設定します。

デフォルト値: 60

例: --my-sql-settings '{"ExecuteTimeout": 1500}'
ServerTimezone

ソース MySQL データベースのタイムゾーンを指定します。

例: --my-sql-settings '{"ServerTimezone": "US/Pacific"}'
AfterConnectScript

がエンドポイントに接続した直後 AWS DMS に実行するスクリプトを指定します。移行タスクは、SQLステートメントが成功したか失敗したかにかかわらず、実行を継続します。

有効な値: セミコロンで区切られた 1 つ以上の有効なSQLステートメント。

例: --my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'
CleanSrcMetadataOnMismatch

不一致が発生すると、レプリケーションインスタンスのテーブルメタデータ情報をクリーンアップして再作成します。例えば、テーブルDDLで変更を実行すると、レプリケーションインスタンスにキャッシュされているテーブルに関する情報が異なる可能性があります。Boolean。

デフォルト値: false

例: --my-sql-settings '{"CleanSrcMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl

AWS DMS は、My のパーティションテーブルDDLの変更をサポートしていませんSQL。 AWS DMS バージョン 3.4.6 以降では、これを に設定すると、 中のパーティションDDL変更に対するテーブルの停止がtrueスキップされますCDC。 は partitioned-table-related AWS DMS を無視しDDL、さらにバイナリログの変更の処理を続行します。

デフォルト値: false

例: --my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'
IgnoreOpenXaTransactionsCheck

AWS DMS バージョン 3.5.0 以降では、タスクが起動時にオープン XA トランザクションを無視するかどうかを指定します。ソースに XA トランザクションがある場合はこれを false に設定する。

デフォルト値: true

例: --my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'

My のソースデータ型SQL

次の表は、 の使用時にサポートされる MySQL データベースのソースデータ型 AWS DMS と AWS DMS 、データ型からのデフォルトのマッピングを示しています。

ターゲットにマッピングされるデータ型を表示する方法については、使用しているターゲットエンドポイントのセクションをご参照ください。

AWS DMS データ型の詳細については、「」を参照してくださいAWS Database Migration Service のデータ型。

データSQL型

AWS DMS データ型

INT

INT4

BIGINT

INT8

MEDIUMINT

INT4

TINYINT

INT1

SMALLINT

INT2

UNSIGNED TINYINT

UINT1

UNSIGNED SMALLINT

UINT2

UNSIGNED MEDIUMINT

UINT4

UNSIGNED INT

UINT4

UNSIGNED BIGINT

UINT8

DECIMAL(10)

NUMERIC (10,0)

BINARY

BYTES(1)

BIT

BOOLEAN

BIT(64)

BYTES(8)

BLOB

BYTES(65535)

LONGBLOB

BLOB

MEDIUMBLOB

BLOB

TINYBLOB

BYTES(255)

DATE

DATE

DATETIME

DATETIME

DATETIME 括弧で囲まれていない はミリ秒なしでレプリケートされます。括弧で囲DATETIMEまれた値が 1～5 ( などDATETIME(5)) の はミリ秒単位でレプリケートされます。

DATETIME 列をレプリケートする場合、時間はターゲットで同じままです。に変換されませんUTC。

TIME

STRING

TIMESTAMP

DATETIME

TIMESTAMP 列をレプリケートすると、時間はターゲットUTCの に変換されます。

YEAR

INT2

DOUBLE

REAL8

FLOAT

REAL(DOUBLE)

FLOAT 値が次の範囲にない場合は、変換を使用して FLOATにマッピングしますSTRING。変換の詳細については、「 変換ルールおよび変換アクション」をご参照ください。

サポートされているFLOAT範囲は、-1.79E+308 から -2.23E-308、0、および 2.23E-308 から 1.79E+308 です。

VARCHAR (45)

WSTRING (45)

VARCHAR (2000)

WSTRING (2000)

VARCHAR (4000)

WSTRING (4000)

VARBINARY (4000)

BYTES (4000)

VARBINARY (2000)

BYTES (2000)

CHAR

WSTRING

TEXT

WSTRING

LONGTEXT

NCLOB

MEDIUMTEXT

NCLOB

TINYTEXT

WSTRING(255)

GEOMETRY

BLOB

POINT

BLOB

LINESTRING

BLOB

POLYGON

BLOB

MULTIPOINT

BLOB

MULTILINESTRING

BLOB

MULTIPOLYGON

BLOB

GEOMETRYCOLLECTION

BLOB

ENUM

WSTRING (length)

ここで、 lengthは 内の最長値の長さですENUM。

SET

WSTRING (length)

ここで、 lengthはカンマを含む SET内のすべての値の合計長です。

JSON

CLOB
注記

場合によっては、「ゼロ」値 (つまり、0000-00-00) で DATETIMEおよび TIMESTAMP データ型を指定できます。その場合は、レプリケーションタスクのターゲットデータベースが DATETIMEおよび TIMESTAMP データ型の「ゼロ」値をサポートしていることを確認してください。サポートされていない場合、これらの値はターゲットで NULL として記録されます。