Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

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

フォーカスモード
MySQL 互換データベースの AWS DMSのソースとしての使用 - AWS Database Migration Service

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

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

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

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

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

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

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

AWS DMSを使用して MySQL から MySQL へ移行します。

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

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

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

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

  • [REPLICATION CLIENT] (レプリケーション クライアント) – この権限は、CDC タスクにのみ必要です。つまり、フルロードのみのタスクにはこの権限は必要ありません。

  • [REPLICATION SLAVE] (レプリケーション スレーブ) – この権限は、CDC タスクにのみ必要です。つまり、フルロードのみのタスクにはこの権限は必要ありません。

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

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

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

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

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

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

  • MySQL Community Edition

  • MySQL Standard Edition

  • MySQL Enterprise Edition

  • MySQL Cluster Carrier Grade Edition

  • MariaDB Community Edition

  • MariaDB Enterprise Edition

  • MariaDB Column Store

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

パラメータ

server_id

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

log-bin

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

binlog_format

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

expire_logs_days

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

binlog_checksum

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

binlog_row_image

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

log_slave_updates

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

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

  • DMS タスクが開始する前に、トランザクションがプライマリインスタンスにコミットされた。

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

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

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

パラメータ

ndb_log_bin

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

ndb_log_update_as_write

このパラメータは OFF に設定します。この値に設定すると、UPDATE ステートメントが INSERT ステートメントとしてバイナリログに書き込まれなくなります。

ndb_log_updated_only

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

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

のソースとして、以下の AWSマネージド MySQL 互換データベースを使用できます AWS DMS。

  • MySQL Community Edition

  • MariaDB Community Edition

  • Amazon Aurora MySQL 互換エディション

のソースとして AWSマネージド MySQL 互換データベースを使用する場合は 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マネージド MySQL 互換データベースはバイナリログをできるだけ早く消去するため、ログが利用可能なままである時間を増やす必要があります。たとえば、ログ保持を 24 時間に伸ばすには、次のコマンドを実行します。

    call mysql.rds_set_configuration('binlog retention hours', 24);
  • binlog_format パラメータを "ROW" に設定します。

    注記

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

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

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

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

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

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

  • 変更データキャプチャ (CDC) は、Amazon RDS MySQL 5.5 以下ではサポートされていません。Amazon RDS for MySQL の場合、CDC を有効にするには、バージョン 5.6、5.7、または 8.0 を使用する必要があります。CDC は、セルフ管理 MySQL 5.5 ソースでサポートされています。

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

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

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

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

  • Aurora MySQL 互換エディションサーバーレス v1 はフルロードで使えますが、CDC には使えません。これは MySQL の前提条件を有効にできないためです。詳細については、「パラメータグループと Aurora サーバーレス v1」をご参照ください。

    Aurora MySQL 互換エディションのサーバーレス v2 は CDC をサポートしています。

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

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

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

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

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

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

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

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

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

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

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

  • AWS DMS は、MySQL のパーティションテーブルの DDL 変更をサポートしていません。CDC 中にパーティション DDL が変更されてもテーブルが中断されないようにするには、skipTableSuspensionForPartitionDdltrue に設定します。

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

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

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

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

  • AWS DMS は、InnoDB ストレージエンジンを使用して MySQL データベースの ON DELETE CASCADE イベントと ON UPDATE CASCADE イベントを伝達しません。 InnoDB このようなイベントについては、MySQL は子テーブルでのカスケード操作を反映する binlog イベントを生成しません。したがって、 AWS DMS は対応する変更を子テーブルにレプリケートできません。詳細については、「インデックス、外部キー、カスケード更新、または削除が移行されない」を参照してください。

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

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

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

  • 内部 MySQL の制限により、 は 4GB 以下のサイズの BINLOGs を処理 AWS DMS できます。4GB を超える BINLOGs、DMS タスクの失敗やその他の予期しない動作を引き起こす可能性があります。4GB を超える BINLOGs を回避するには、トランザクションのサイズを小さくする必要があります。

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

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

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

    grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';
  • エンドポイント設定 IgnoreOpenXaTransactionsCheckfalse に設定する。

注記

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

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

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

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

名前 説明
EventsPollInterval

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

デフォルト値: 5

有効な値: 1~60

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

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

ExecuteTimeout

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

デフォルト値: 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 は、MySQL のパーティションテーブルの DDL 変更をサポートしていません。 AWS DMS バージョン 3.4.6 以降では、これを に設定すると、CDC 中にパーティション DDL の変更によるテーブルの停止がtrueスキップされます。 はpartitioned-table-related DDL AWS DMS を無視し、引き続きバイナリログの変更を処理します。

デフォルト値: false

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

IgnoreOpenXaTransactionsCheck

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

デフォルト値: true

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

MySQL のソースデータ型

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

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

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

MySQL のデータ型

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 は、ミリ秒なしでレプリケートされる。括弧内の値が 1~5 (DATETIME(5) など) の DATETIME は、ミリ秒単位でレプリケートされる。

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] (長さ) は列挙型の最長値の長さです。

SET

WSTRING ([length] (長さ))

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

JSON

CLOB

注記

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

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.