資料庫搬到Cloud SQL - 使用AWS DMS服務
Google CloudSQL提供高品質的資料服務，但在使用之前，一般大家會問到該怎麼把資料庫搬到CloudSQL的環境，CloudSQL提供透過 Cloud Storage來做 import/export，如果再資料量不是很大的狀況下，直接針對資料庫做 export 然後存放到 Cloud Storage後，再 import 到 CloudSQL 的速度還滿快的... 但是如果需要做到持續同步資料，則我們會需要一些規劃與工具來持續同步您的資料。
AWS DMS在資料轉移上是一個不錯的選擇，透過簡單的設定流程，可以快速的備份你的資料從一個Database到另一個Database，這裡以MySQL與CloudSQL為例，給大家參考：
建立步驟如下:
Step1 建立Replication Instances
Step2 Replication Instances建好之後會給一組IP address，將這組IP加入你的DB network DMS:
另外，GCE需要加入DMS的IP:
Cloud SQL 加入DMS的IP:
Step3 建立source、target的Endpoints
Step 4 建立Tasks
指定從哪一個source到哪一個target，要migrate哪個database哪些table。
建立完成後，若沒有錯誤資料就會開始備份...
情境測試:
1.測試Table內有特殊設定的欄位
- 有sequence的Table
結果: 轉到Cloud sql上，設定會不見，要再自己加入
- 有fk的Table
結果: 轉到Cloud sql上，設定會不見，要再自己加入
- 有timestamp的Table
結果: 轉到Cloud sql上，設定會不見，要再自己加入
2.轉10000筆& 100000筆的時間差?
如果是直接從DMS上做Migrate existing data，5分鐘內資料就會sync到目的端；若是用Replicate data changes only，一筆一筆sync時間就會拉的比較長。
3.當schema相同，加入異動資料時會有什麼情況?
- Migration type：Migrate existing data > 做一次性的sync
- Target table preparation mode：Do nothing
結果: 若已有相同的pk的資料存在，那筆資料不會異動，會加入目的端沒有的資料。
- Target table preparation mode：Drop tables on target
結果:目的端若已存在相同名字的Table，Table會重建，資料會被覆蓋。
- Target table preparation mode：Truncate
結果:目的端若已存在相同名字的Table，Table不會重建，資料會被覆蓋。
- Migration type：Migrate existing data and replicate ongoing changes >第一次會做資料sync並持續針測資料是否有異動
- Target table preparation mode：Do nothing
結果:
目的端原有的資料不會改變，會加入目的端沒有的資料。當來源端有資料新增、修改時，目的端會同步。
- Target table preparation mode：Drop tables on target
結果:
目的端的Table會被重建，資料被覆蓋。當來源端有資料新增、修改時，目的端會同步。
- Target table preparation mode：Drop tables on target
結果:
資料會整個被覆蓋，但Table不會重新建置。當來源端有資料新增、修改時，目的端會同步。
- Migration type：Replicate data changes only > 只會針測資料是否有異動
- Target table preparation mode：不論選哪一個
結果:原有的資料不會被覆蓋，table也不會被重新建置，當Table的資料有異動的時候，才會同步資料。
PS：要做異動資料的同步前，要在source那台的mysql設定這些參數
