資料庫搬到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設定這些參數
留言
張貼留言