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

# のソースとしての MySQL 互換データベースの使用 AWS DMS
<a name="CHAP_Source.MySQL"></a>

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

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

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

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

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

**Topics**
+ [

## を使用した MySQL から MySQL への移行 AWS DMS
](#CHAP_Source.MySQL.Homogeneous)
+ [

## のソースとしての MySQL 互換データベースの使用 AWS DMS
](#CHAP_Source.MySQL.Prerequisites)
+ [

## のソースとしてのセルフマネージド MySQL 互換データベースの使用 AWS DMS
](#CHAP_Source.MySQL.CustomerManaged)
+ [

## のソースとしての AWSマネージド MySQL 互換データベースの使用 AWS DMS
](#CHAP_Source.MySQL.AmazonManaged)
+ [

## MySQL データベースを のソースとして使用する場合の制限 AWS DMS
](#CHAP_Source.MySQL.Limitations)
+ [

## XA トランザクションのサポート
](#CHAP_Source.MySQL.XA)
+ [

## のソースとして MySQL を使用する場合のエンドポイント設定 AWS DMS
](#CHAP_Source.MySQL.ConnectionAttrib)
+ [

## MySQL のソースデータ型
](#CHAP_Source.MySQL.DataTypes)

**注記**  
 AWS Database Migration Service (AWS DMS) マッピングルールを設定するときは、データベース名またはスキーマ名にワイルドカード (%) を使用しないことが重要です。その代わりに、移行する必要があるユーザー作成のデータベースのみを明示的に指定する必要があります。ワイルドカード文字の使用には、ターゲットインスタンスで必要ではないシステムデータベース、および移行プロセス内のすべてのデータベースが含まれます。MySQL Amazon RDS マスターユーザーには、ターゲットシステムデータベースにデータをインポートするために必要なアクセス許可がないため、これらのシステムデータベースの移行は失敗します。

## を使用した MySQL から MySQL への移行 AWS DMS
<a name="CHAP_Source.MySQL.Homogeneous"></a>

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

## のソースとしての MySQL 互換データベースの使用 AWS DMS
<a name="CHAP_Source.MySQL.Prerequisites"></a>

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

レプリケーション管理者ロール AWS DMS を持つ のアカウントが必要です。ロールには、次の権限が必要です。
+ **[REPLICATION CLIENT]** (レプリケーション クライアント) – この権限は、CDC タスクにのみ必要です。つまり、フルロードのみのタスクにはこの権限は必要ありません。
**注記**  
MariaDB バージョン 10.5.2 以降では、BINLOG MONITOR を使用できます。これは REPLICATION CLIENT に代わるものです。
+ **[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
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only
```

RDS ソースを使用していて、MySQL 固有の移行前評価を実行する予定がある場合は、次のアクセス許可を追加します。

```
grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check
```

パラメータ `BatchEnable` が `true` の場合、以下を付与する必要があります。

```
grant create temporary tables on `<schema>`.* to <dms_user>;
```

## のソースとしてのセルフマネージド MySQL 互換データベースの使用 AWS DMS
<a name="CHAP_Source.MySQL.CustomerManaged"></a>

次のセルフマネージド型 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_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` に設定します。 | 

**既存のデータを移行して継続的な変更をレプリケートする**を使用して 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
<a name="CHAP_Source.MySQL.AmazonManaged"></a>

のソースとして、以下の 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 ユーザーガイド*の「[自動バックアップの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)」をご参照ください。

  Amazon RDS for MySQL データベースのバイナリログ設定の詳細については、*Amazon RDS ユーザーガイド*の「[バイナリログ形式の設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)」をご参照ください。

  Aurora MySQL クラスターのバイナリログ設定の詳細については、「[Amazon Aurora MySQL クラスターのバイナリログを有効にする方法](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/)」をご参照ください。
+ CDC を使用する予定の場合は、バイナリログを有効にします。Amazon RDS for MySQL データベースのバイナリログの設定の詳細については、*Amazon RDS ユーザーガイド*の「[バイナリログ形式の設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)」をご参照ください。
+ バイナリログが使用可能であることを確認します AWS DMS。 AWSマネージド MySQL 互換データベースはバイナリログをできるだけ早く消去するため、ログが利用可能なままになる時間を増やす必要があります。たとえば、ログ保持を 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 以前の場合、`binlog_checksum` パラメータを `"NONE"` に設定します。Amazon RDS MySQL でのパラメータの設定の詳細については、*Amazon RDS ユーザーガイド*の「[自動バックアップの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)」をご参照ください。
+ Amazon RDS MySQL または Amazon RDS MariaDB リードレプリカをソースとして使用する場合は、リードレプリカでバックアップを有効にして、`log_slave_updates` パラメータが `TRUE` と設定されていることを確認します。

## MySQL データベースを のソースとして使用する場合の制限 AWS DMS
<a name="CHAP_Source.MySQL.Limitations"></a>

MySQL データベースをソースとして使用する場合は、次の点を考慮してください。
+  変更データキャプチャ (CDC) は、Amazon RDS MySQL 5.5 以下ではサポートされていません。Amazon RDS for MySQL の場合、CDC を有効にするには、バージョン 5.6、5.7、または 8.0 を使用する必要があります。CDC は、セルフ管理 MySQL 5.5 ソースでサポートされています。
+ CDC の場合、列データ型を変更する `CREATE TABLE`、`ADD COLUMN`、`DROP COLUMN`、`renaming a column` がサポートされています。ただし、`DROP TABLE`、`RENAME TABLE`、およびカラムのデフォルト値、カラムのNULL可能性、文字セットなどの他の属性に対する更新はサポートされていません。
+  ソースのパーティションテーブルの場合、**ターゲットテーブル準備モード**を**ターゲットのテーブルの削除**に設定すると、 は MySQL ターゲットにパーティションなしでシンプルなテーブル AWS DMS を作成します。パーティション分割されたテーブルをターゲットのパーティション分割されたテーブルに移行するには、ターゲット MySQL データベースにパーティション分割されたテーブルを事前に作成します。
+  `ALTER TABLE table_name ADD COLUMN column_name` ステートメントを使用してテーブルの先頭 (FIRST) または中間 (AFTER) に列を追加することは、リレーショナルターゲットではサポートされていません。列は常にテーブルの末尾に追加されます。ターゲットが Amazon S3 または Amazon Kinesis Data Streams の場合、FIRST または AFTER を使用した列の追加がサポートされます。
+ テーブル名に大文字と小文字が含まれていて、大文字と小文字が区別されるオペレーティングシステムにソースエンジンがホストされている場合、CDC はサポートされません。たとえば、Microsoft Windows や HFS\$1 を使用する OS X などです。
+ Aurora MySQL 互換エディションサーバーレス v1 はフルロードで使えますが、CDC には使えません。これは MySQL の前提条件を有効にできないためです。詳細については、「[パラメータグループと Aurora サーバーレス v1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html#aurora-serverless.parameter-groups)」をご参照ください。

  Aurora MySQL 互換エディションのサーバーレス v2 は CDC をサポートしています。
+  列の AUTO\$1INCREMENT 属性は、ターゲットデータベース列に移行されません。
+  バイナリログが標準のブロックストレージに保存されている場合の変更のキャプチャはサポートされていません。たとえば、バイナリログが Amazon S3 に保存されていると、CDC は機能しません。
+  AWS DMS は、デフォルトで InnoDB ストレージエンジンを使用してターゲットテーブルを作成します。InnoDB 以外のストレージエンジンを使用する必要がある場合、テーブルを手動で作成し、[何もしない](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html)モードを使用してそのテーブルに移行する必要があります。
+ DMS 移行タスクモードが**既存のデータの移行** - フルロードのみである AWS DMS 場合を除き、Aurora MySQL レプリカを のソースとして使用することはできません。
+  全ロード時に MySQL 互換ソースが停止している場合、 AWS DMS タスクはエラーで停止しません。タスクは正常に終了しますが、ターゲットとソースが同期しない可能性があります。この場合、タスクを再開するか、影響を受けたテーブルを再ロードしてください。
+  列の値の一部で作成されたインデックスは移行されません。たとえば、インデックス CREATE INDEX first\$1ten\$1chars 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 が変更されてもテーブルが中断されないようにするには、`skipTableSuspensionForPartitionDdl` を `true` に設定します。
+ AWS DMS は、バージョン 3.5.0 以降の XA トランザクションのみをサポートします。以前のバージョンでは XA トランザクションはサポートされていません。MariaDB バージョン 10.6 以降の XA トランザクション AWS DMS はサポートされていません。詳細については、[XA トランザクションのサポート](#CHAP_Source.MySQL.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 は対応する変更を子テーブルにレプリケートできません。詳細については、「[インデックス、外部キー、カスケード更新、または削除が移行されない](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.FKsAndIndexes)」を参照してください。
+ AWS DMS は、計算された (`VIRTUAL` および `GENERATED ALWAYS`) 列の変更をキャプチャしません。この制限を回避するには、次の手順を実行します。
  + ターゲットデータベースにターゲットテーブルを事前に作成して、`DO_NOTHING`または `TRUNCATE_BEFORE_LOAD` のフルロード設定の AWS DMS タスク設定を使用してタスクを作成する。
  + 計算列をタスクスコープから削除する変換ルールを追加する。変換ルールの詳細については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」を参照。
+ 内部 MySQL の制限により、 は 4GB 以下のサイズの BINLOGs を処理 AWS DMS できます。BINLOGが 4GB を超えると、DMS タスクの障害やその他の予期しない動作が発生する可能性があります。4GB を超える BINLOG を回避するには、トランザクションのサイズを小さくする必要があります。
+ AWS DMS は、スキーマ、テーブル、および列名でバックティック (```) または一重引用符 (`'`) をサポートしていません。
+ AWS DMS は、ソースデータベース内の非表示の列からデータを移行しません。このような列を移行の範囲に含めるには、ALTER TABLE ステートメントを使用して列を表示します。

## XA トランザクションのサポート
<a name="CHAP_Source.MySQL.XA"></a>

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

  ```
  grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';
  ```
+ エンドポイント設定 `IgnoreOpenXaTransactionsCheck` を `false` に設定する。

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

## のソースとして MySQL を使用する場合のエンドポイント設定 AWS DMS
<a name="CHAP_Source.MySQL.ConnectionAttrib"></a>

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

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

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html)

## MySQL のソースデータ型
<a name="CHAP_Source.MySQL.DataTypes"></a>

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

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

 AWS DMS データ型の詳細については、「」を参照してください[AWS Database Migration Service のデータ型](CHAP_Reference.DataTypes.md)。


|  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 にマップする。変換の詳細については、「[変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)」をご参照ください。 サポートされる FLOAT の範囲は、-1.79E\$1308～-2.23E-308、0、2.23E-308～1.79E\$1308。  | 
|  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 として記録されます。