thắc mắc migrate data từ PROD sang DEV environment trên google cloud SQL for PostgreSQL

jerryno6

Senior Member
Hi các bác, mình nhờ các bác nào có kinh nghiệm bên google cloud tư vấn với.

[Hiện trạng]
Mình đang có một google cloud SQL instance for PostgreSQL tên là PROD, trong đó có 5 database. mình đang muốn build 1 instance cloud SQL for PostgreSQL khác tương tự đặt tên là DEV.

[Mong muốn]
Mình muốn tìm 1 cách nào đó để có thể hằng ngày tự động việc lấy dữ liệu mới nhất của 1 database từ PROD đẩy về 1 db trong instance DEV với điều kiện:
1. Lấy dữ liệu mới nhất từ từ PROD để đổ vào trong DEV instance.
2. Chỉnh sửa lại dữ liệu nhạy cảm, ví dụ thông tin địa chỉ khách hàng, tên khách hàng của database trong DEV.

[Giải pháp đã thử]
giải pháp nocode từ google:
  • Google Cloud backup and DR, cái này chỉ dùng được cho DB onpremise.
  • DB Migration Service: thấy nó chỉ kéo dữ liệu về được thôi, còn bước Conversion Workspace thì source database không hỗ trợ google cloud SQL. Trong khi mình muốn nó vừa kéo dữ liệu về và vừa chạy script SQL để update hoặc là có cách nào đó để chuyển đỏi/ generate ra dữ liệu cho những field nhạy cảm trong một table nào đó thành fake data sau khi đã kéo dữ liệu mới nhất từ PROD về.
Nhờ các bác tư vấn thêm giúp mình còn giải pháp nocode nào khả thi không?

Còn giải pháp phải code thì mình còn solution:
- Tạo 1 scheduler code cho nó chạy 1 lệnh google cli để restore backup của PROD sang bên DEV, sau đó code tiếp cho nó chạy 1 script SQL để update sửa lại những field thông tin nhạy cảm, ví dụ như field customer_address, customer_name. Cái này thì hơi phiền vì còn phải dính nhiều cái khác như pubsub, lambda, permisson, role, VPC, và phải làm sao để nó đợi việc restore thành công rồi mới tiến hành update data.

Nhờ các bác có kinh nghiệm với google cloud hỗ trợ thêm.
 
Last edited:
nghiên cứu CDC thử nhé
OK bác, để mình xem thử video giới thiệu của nó xem nó làm dc điều mình cần không.

P/S: sau khi xem video và đọc tài liệu thì thấy chủ yếu nó replicate data từ db vào bigquery à bạn ơi. Và chưa thấy nó có bước nào để chuyển đổi/ thay đổi dữ liệu trongkhi hoặc sau khi replicate cả.
 
Last edited:
OK bác, để mình xem thử video giới thiệu của nó xem nó làm dc điều mình cần không.

P/S: sau khi xem video và đọc tài liệu thì thấy chủ yếu nó replicate data từ db vào bigquery à bạn ơi. Và chưa thấy nó có bước nào để chuyển đổi/ thay đổi dữ liệu trongkhi hoặc sau khi replicate cả.
DB Prod -> CDC -> Kafka Topic -> Viết 1 đoạn Script, Consume dữ liệu từ Kafka rồi Manipulate Data theo ý của bạn rồi quăng lên Serverless -> Sink vào con DB Dev.
 
Nghiên cứu cái này nha thớt, CDC thì debezium hiện tại support tốt nhất rồi, và sử dụng luôn managed service của GCP luôn.

Theo mình biết Debezium có support data masking debezium-data-masking-cdc-poc/connectors/users_sink.json at main · maxkrivich/debezium-data-masking-cdc-poc (https://github.com/maxkrivich/debezium-data-masking-cdc-poc/blob/main/connectors/users_sink.json)

 
OK bác, để mình xem thử video giới thiệu của nó xem nó làm dc điều mình cần không.

P/S: sau khi xem video và đọc tài liệu thì thấy chủ yếu nó replicate data từ db vào bigquery à bạn ơi. Và chưa thấy nó có bước nào để chuyển đổi/ thay đổi dữ liệu trongkhi hoặc sau khi replicate cả.
còn cách nữa là bác chạy job dump data ra .sql/csv rồi sed/code replace content cần che xong import :byebye:
 
Nghiên cứu cái này nha thớt, CDC thì debezium hiện tại support tốt nhất rồi, và sử dụng luôn managed service của GCP luôn.

Theo mình biết Debezium có support data masking debezium-data-masking-cdc-poc/connectors/users_sink.json at main · maxkrivich/debezium-data-masking-cdc-poc (https://github.com/maxkrivich/debezium-data-masking-cdc-poc/blob/main/connectors/users_sink.json)

Cám ơn bạn, giờ mới biết cái debezium này, để đọc thử xem sao.
 
còn cách nữa là bác chạy job dump data ra .sql/csv rồi sed/code replace content cần che xong import :byebye:
cách này thì cũng giống như cách chạy backup daily lúc 1h (cái này thì không cần phải làm, vì mình setup db PROD luôn có backup daily rồi), sau đó code script nào đó để restore lúc 2h sau đó tự động chạy code để replace ccontent lúc 3 hoặc 4h. Giải pháp cũng gần giống nhau. riêng cái vụ backup/restore thì nó lâu hơn thôi, vì nó backup và restore cả đống database ở trong cái instance đó. Còn job dump data thì chỉ lấy dữ liệu của 1 database duy nhất, nên có vẻ tối ưu hơn chút.
 
Debezium kafka connect nha fence
zFNuZTA.gif


via theNEXTvoz for iPhone
 
cách này thì cũng giống như cách chạy backup daily lúc 1h (cái này thì không cần phải làm, vì mình setup db PROD luôn có backup daily rồi), sau đó code script nào đó để restore lúc 2h sau đó tự động chạy code để replace ccontent lúc 3 hoặc 4h. Giải pháp cũng gần giống nhau. riêng cái vụ backup/restore thì nó lâu hơn thôi, vì nó backup và restore cả đống database ở trong cái instance đó. Còn job dump data thì chỉ lấy dữ liệu của 1 database duy nhất, nên có vẻ tối ưu hơn chút.
khác nhau chứ, restore backup là nguyên cục (db A 100gb phải backup restore cả 100gb đó) trong khi bác chỉ cần cập nhật data mới cho dev thôi mà.
- job query dump data fillter hôm nay ra .sql/csv -> xử lý hide thông tin trên file dump này -> đẩy lên bucket -> bên dev chỉ cần down về import vào là được ( cons là db dev không sync realtime với prod, tính case job chạy fail thì chạy manual lại.
 
khác nhau chứ, restore backup là nguyên cục (db A 100gb phải backup restore cả 100gb đó) trong khi bác chỉ cần cập nhật data mới cho dev thôi mà.
- job query dump data fillter hôm nay ra .sql/csv -> xử lý hide thông tin trên file dump này -> đẩy lên bucket -> bên dev chỉ cần down về import vào là được ( cons là db dev không sync realtime với prod, tính case job chạy fail thì chạy manual lại.
À ok á bác, nếu chỉ query data mới thì nhẹ hơn hẳn.
 
Mình đọc lướt qua chưa thấy bạn estimate data size thay đổi hằng ngày. Giải pháp thì nhiều nhưng tuỳ vào tình huống.
Nếu chỉ để sync làm DEV env thì không cần tới CDC, tech stack lớn, maintain cực để đạt accuracy, chưa kể change schema ở PROD phải handle schema evolution, etc.
Some solutions:

1. Low code thì dùng Airbyte:
  • nếu table có key thì nó có incremental + append/dedup
  • nếu không có key thì full refresh + overwrite
  • có scheduler, UI dễ xài, deploy với doker-compose/helm
  • có support transform (có thể mask data ở đây - này mình chưa dùng nhiều, cần POC). Hoặc chạy một job để mask data sau khi sync cũng được.

2. Tự implement: require là table phải có created_at or updated_at
  • Làm một cái template để sync data mới cho table. Config yaml/json: db_name, table_name, col_time, col_keys, etc.
  • mỗi lần schedule thì cứ scan data mới rồi dựa theo col_time rồi upsert vào DEV.

=> Cả 2 solution đều có thể ảnh hưởng performance của PROD db (CDC thì tránh được vụ này). => Solution: tạo thêm 1 read replica cho PROD db rồi đọc trên đó để sync qua DEV.
 
cty mà biết là kí đầu bạn đấy nhé, ai cho chơi kiểu đẩy data từ prod về dev r sửa lại trời :D
Cũng bình thường thôi mà, để làm môi trường dev có lượng data gần giống với môi trường thật, những thông tin nhạy cảm thì đã mask lại rồi
 
Back
Top