小ネタ／AWS DMS（CDC）で MySQL to MySQL 移行時のタイムゾーン指定

AWS の DMS（CDC）でソース・ターゲットの両方が MySQL（RDS / Aurora MySQL）の場合、タイムゾーンの指定に注意が必要です。

前提

• DMS 3.4.7 を使用
• ソース・ターゲット各 MySQL サーバのタイムゾーン（time_zone）が正しく設定されている

元の設定がずれている（例：サーバのtime_zone設定がUTCのまま、タイムゾーンを無視してAsia/Tokyoの日時値を保存している）場合は違う状況になります。

ポイント

• AWS DMS（Data Migration Service）の CDC（Change Data Capture）で MySQL（RDS / Aurora MySQL を含む）から MySQL（同）にデータをレプリケーションで移行するときは、 ソースエンドポイントのタイムゾーンを設定しない

理由

MySQL では、内部的に

• TIMESTAMP型の日時は1970-01-01 00:00:01.000000以降のUTC日時
• DATETIME型の日時はタイムゾーンを持たない日時

を保持します。

日時リテラルなどでタイムゾーンを指定した場合、接続（セッション）のタイムゾーンとの差分を調整した値がDATETIME型の列値となります。
例えば、接続（セッション）のタイムゾーンが+09:00（Asia/Tokyo）のときに2020-07-19 18:00:00+00:00を指定してDATETIME型の列に保存した場合、列値は2020-07-20 03:00:00となります。
ただし、列値にタイムゾーン自体を保持しないので、例えば接続（セッション）のタイムゾーンを+00:00（UTC）に変更して同じDATETIME型の列値を読み取ったときには2020-07-20 03:00:00が返ります。

一方、DMS ではどちらもデフォルトで DMS データ型DATETIMEにマッピングされます。

この状況でソースエンドポイントのタイムゾーンとしてUTC以外、例えばAsia/Tokyoを選んで DB に接続したときに、DMS が TIMESTAMP型の値をUTCではなくローカルタイムゾーンの日時値として処理してしまう ようです。つまり、ソース側をUTC以外にしてしまうとTIMESTAMP型の値がずれます。

DATETIME型の値はタイムゾーンを持たず、ソースエンドポイントのタイムゾーンに関わらずそのままの値が移行されます。

結果として、TIMESTAMP型もDATETIME型もタイムゾーンがずれないようにするには、ソースエンドポイントのタイムゾーンをUTC（デフォルトのまま）にしておくのが良いことになります。

ターゲットエンドポイントについては、デフォルト（UTC）のままでもAsia/Tokyoなどを指定しても問題ない模様ですが、特に理由がなければデフォルトのままにしておきます。

別の方法

TIMESTAMP型の列を DMS の文字列型にマッピングすれば、ソースタイムゾーンをUTC以外（Asia/Tokyoなど）にした場合でも正しく移行できるようです。

ただ、DMS のSTRING型を使うには全体の桁数（文字数）の指定（型の後ろにカッコで表記）が必要ですが（指定しないとエラーになります）、TIMESTAMP型における桁数指定は「秒未満の部分の桁数」となり意味が違うので、STRING型ではなくCLOB型を指定するのが良さそうです。