Forbedringer i cloudsql migrator

[mortenlj]

Sondre Lefsaker har gitt oss en haug med gode tilbakemeldinger som bør tas tak i.

Legger dem inn her, men de bør fordeles i mindre (m)initiativer og raffineres litt før de spilles inn skikkelig.

Hentet herfra: https://nav-it.slack.com/archives/C01DE3M9YBV/p1737355501614299?thread_ts=1730124338.356289&cid=C01DE3M9YBV

---

Jeg har kjørt oppsettet for tre clustere i dev nå og har notert ned noen erfaringer fra ting som oppsto mens jeg holdt på som kanskje kan være til nytte for andre også.

Problemer underveis:

• Jeg forsøkte å gjøre setup og promote med to forrskjellige cli-versjoner som krevde manuell opprydning av ressurser før jeg kunne forsøke på nytt. Akkurat for dette tilfellet så kunne det vært nyttig å hatt noe dokumentasjon på hvilke ressurser som ble opprettet av scriptet, men jeg klarte å finne frem via kubectl og Asset Inventory i GCP og slettet alle ressurser som hadde noe med migration|migrator i navnet. Den siste jokeren som også måtte slettes manuelt var SSL-sertifikatet til migreringsjobben i selve database-clusteret. Jeg tviler på at dette er en situasjon som vil oppstå veldig ofte, men jeg synes likevel at det er nyttig å vite hva som beveger seg i miljøet når man kjører slike typer kommandoer.
• Jeg klarte også å rote til et av forsøkene i steget fra promote til finalize ved at en deployment av appen ble trigget via Github Actions, noe som førte til at nais deployet en ny versjon av appen med gammelt database-cluster mens finalize holdt på med å slette de samme ressursene. Dette gjorde at finalize ende i en slags deadlock (husker ikke akkurat hvilket steg det var på). Dette fikk jeg også løst ved å manuelt slette deployment og database secret til app'en via kubectl etterfulgt av å deploye app'en på nytt, med det nye database-clusteret definert i nais.yaml.
• På den neste app'en gikk jeg for å oppdatere nais.yaml med nytt cluster før jeg startet finalize for å unngå samme tabbe, men dette kan f.eks. løses ved å hindre deployments fra Github Actions mens man holder på også.
• Den siste app'en jeg migrerte var også konfigurert opp med en replication slot og en publication for CDC via datastream til bigquery, som beskrevet av Nada. Her var det et par ting som måtte fikses manuelt:
  Selve database-brukeren (med navn datastream i vår db) ble overført til nytt cluster, men sql-secret'en (med passord, etc) ble slettet under promote ser det ut til. Dette førte til at applikasjonen sto i tilstanden CreateContainerConfigError med feilen Error: secret "google-sql-mulighetsrommet-api-mulighetsrommet-api-db--184f872d" not found etter at promote hadde kjørt ferdig. Dette løste jeg på følgende måte:
  Først deploye en ny versjon av app'en med nytt databasecluster (for ikke å repetere tabben beskrevet over), samt at jeg fjernet alle ekstra database-brukere definert i sqlInstances.0.users i nais.yaml
  Deretter gjorde jeg en ny deploy der jeg la til datastream-brukeren på nytt under sqlInstances.0.users i nais.yaml, noe som trigget at secret'en for datastream-brukeren ble opprettet på nytt
  I tillegg til at selve datastream-brukeren ble med videre til nytt cluster, så ble også innstillingene for publications ble overført (altså flagget cloudsql.logical_decoding=on, samt publication definert i pg_publication og alle tabellene dette var skrudd dette på for definert i pg_publication_tables), men replication-innstillingene ble ikke overført.
  Dette måtte jeg fikse manuelt i nytt databasecluster ved å kjøre tre ekstra sql-statements:

alter user "<navn på ny databasebruker/det samme som nytt cluster-navn>" with replication;         
alter user "datastream" with replication;
select pg_create_logical_replication_slot('ds_replication', 'pgoutput');

Siden clusteret uansett hadde fått nytt navn så endte jeg opp med å erstatte eksisterende datastream og cloud sql proxy VM med helt nye instanser.

Noen ekstra betraktninger:

• Når man kjører de forskjellige kommandoene (setup, promote, finalize) så er det ikke uvanlig at flere av stegene feiler og prøves på nytt. Typisk rundt 3 ganger per kommando.
  • Dette ser ut til å være forventet oppførsel, antagelig fordi det tar tid å opprette nye ressurser i GCP og at jobbene som kjøres er bygget for å være robuste mtp. dette. Stort sett hentet de seg inn igjen etter litt tid, men hvis man er utålmodig når man kjører dette så kan det tenkes at man avslutter jobben litt for tidlig fordi det kan virke som at at den har satt seg helt fast.
  • Bl.a. fikk jeg stort sett følgende flere ganger på rad under setup:

    2025-01-17 12:12:16 ERROR failed to prepare source instance
        └ error: Get "https://api.ipify.org/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)`
    

  • Og følgende et par ganger under promote:

      2025-01-16 14:27:18 ERROR Migration is not ready for promotion                                                  
         └ error: failed to get migration job: failed to get migration job: 
       Get "https://datamigration.googleapis.com/v1/projects/<migration job>": credentials: cannot fetch token: 
       Get "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform": dial tcp 169.254.169.254:80: i/o timeout
    

  • Kanskje denne oppførselen også burde nevnes i dokumentasjonen?
• Det hadde vært kjekt om ekstra databasebrukere definert i nais.yaml også fikk med seg secret til ny app når man kjører promote, evt. dokumentere hvordan man burde behandle disse ifm. migrering.