Este posibil să specificați o instanță CloudSQL existentă ca destinație pentru serviciul de migrare a bazei de date în GCP?

Conform ghidurilor GCP, configurarea unei migrări a bazei de date implică crearea unui job de migrare în consolă folosind vrăjitorul [1]. Expertul creează o nouă instanță CloudSQL, dar aș dori să specific o instanță existentă astfel încât să putem gestiona instanța de destinație prin controlul versiunii (de exemplu, Terraform)

Este posibil să specificați o instanță CloudSQL existentă ca destinație pentru serviciul de migrare a bazei de date în GCP? Dacă da, cum?

Dacă nu, o altă soluție pentru controlul versiunilor este să creați jobul de migrare (și, eventual, instanța de destinație) printr-un script care rulează comenzi Gcloud CLI/API.

Din ghidurile API pentru migrarea bazei de date [2], se pare că trebuie să specificăm a destinaţie profilul de conexiune.

destination-connection-profile-id: ID-ul profilului de conexiune de destinație

Acest lucru se reflectă în documentele CLI gcloud [3]

--destination=DESTINATIE
ID-ul profilului_conexiune sau identificatorul complet calificat pentru profilul_conexiune. Pentru a seta atributul connection_profile:
furnizați argumentul --destination pe linia de comandă.

Înseamnă asta că, pentru a crea jobul de migrare prin CLI, va trebui să creez manual o instanță CloudSQL de destinație ȘI un profil de conexiune și pentru acea instanță? Dacă da, de ce privilegii are nevoie utilizatorul conexiunii? Sau comanda „gcloud database-migration migration-jobs create” creează automat o instanță de destinație?

În caz contrar, deschideți-vă sugestiilor cu privire la ce ar putea însemna steagul --destination.

[1] https://cloud.google.com/database-migration/docs/mysql/create-migration-job

[2] https://cloud.google.com/database-migration/docs/mysql/api-migration-jobs#create_a_continuous_migration_job_with_reverse_ssh_connectivity

[3] https://cloud.google.com/sdk/gcloud/reference/database-migration/migration-jobs/create

Ai pus următoarele întrebări:

• Este posibil să specificați o instanță CloudSQL existentă ca destinație pentru serviciul de migrare a bazei de date în GCP?

• Comanda „gcloud database-migration migration-jobs create”? creați automat o instanță de destinație?

• Înseamnă asta că pentru a crea jobul de migrare prin CLI, I va trebui să creeze manual o instanță CloudSQL de destinație ȘI a profil de conexiune și pentru acel caz?

• Răspuns la prima întrebare: Nu, nu este posibil. Parerea mea este Serviciul de migrare a bazei de date va crea întotdeauna o instanță nouă. Când utilizați expertul/consola pentru a efectua serviciul de migrare, când faceți clic pe creați o destinație, creează automat o nouă Instanță de destinație Cloud SQL pentru dvs. Când utilizați API-ul, sunteți se așteaptă să creeze profilul de destinație. Vezi asta legătură unde este a menționat „Creați un profil de conexiune pentru Cloud SQL pentru MySQL destinație... Serviciul de migrare a bazelor de date pentru MySQL folosește informații din această solicitare pentru a crea un nou Cloud SQL pentru MySQL instanță."

  Cred că ar fi destul de dificil să faci serviciul să funcționeze în mod fiabil dacă nu am crea o instanță nouă de fiecare dată. Acestea fiind spuse, cred că serviciul, așa cum există acum, este conceput pentru a putea susține mai mult opțiuni în viitor, așa că s-ar putea întâmpla, dar nu văd niciuna dovada că se poate face acum.

• Răspuns la a doua întrebare: Nu, nu o creează. Când alergi comanda âgcloud database-migration migration-jobs createâ, trebuie să fie create profilurile de conexiune sursă și destinație și dat ca parametri acestei comenzi conform documentație.

• Răspuns la a treia întrebare: Nu. Pentru a face acest lucru folosind gcloud (sau API-ul) trebuie să creați profilurile de conexiune sursă și destinație, apoi va fi creată jobul de migrare și instanța de destinație pentru dumneavoastră conform informațiilor furnizate Aici.

Preocuparea dvs. cu privire la modul de a gestiona acest lucru cu terraform este probabil validă și poate interesantă, dar terraform este un produs terță parte, iar Google nu construiește API-urile având în vedere modelul său. Poate că ați putea crea o problemă cu asta și cineva din acel scop o poate analiza.

Este regretabil că Google a ales să implementeze această soluție în acest fel. La început am crezut că este mai asemănătoare cu abordarea AWS, în care DMS creează o instanță de bază de date intermediară pentru a migra / manipula datele înainte de a le replica în instanța țintă / motorul DB.

În speranța că vor evolua acest lucru în timp, dar deocamdată nu pare a fi un produs complet complet