Replikera data till Lakebase

Den här guiden visar hur du kan replikera data från en extern Postgres-databas till Lakebase med hjälp av logisk replikering. Lakebase fungerar som prenumerant: det ansluter till din källdatabas, kopierar den befintliga datan och tillämpar fortlöpande ändringar tills du växlar över. Använd detta för att migrera en databas från en annan Postgres-leverantör, såsom Amazon Aurora PostgreSQL eller Amazon RDS för PostgreSQL, eller från en självhanterad Postgres-server till Lakebase.

Förutsättningar

  • En källdatabas i Postgres med en publik endpoint som Lakebase kan nå.
  • Superanvändaråtkomst på källdatabasen, eller administratörskontot på en hanterad Postgres-tjänst. Att sätta wal_level, skapa en roll med attributet REPLICATION och skapa en publikation kräver alla den här åtkomstnivån.
  • Ett Lakebase-projekt för måldatabasen.
  • En Lakebase Postgres-roll för att skapa prenumerationen: en medlem i databricks_superuser rollen, eller en roll som tilldelats den pg_create_subscription förutdefinierade rollen. Se avsnittet Skapa Postgres-roller.

Logisk replikation stöds i Lakebase. Det finns inget steg per projekt för att aktivera det. Som abonnent kräver Lakebase ingen wal_level ändring. Endast källförlaget behöver wal_level = logical.

Förbered källdatabasen

I din källdatabas Postgres, ställ in write-ahead-loggen till logical och bekräfta att det finns kapacitet för replikering. Följande exempel gäller självhanterad Postgres. Din hanterade Postgres-leverantör kan använda andra inställningar:

ALTER SYSTEM SET wal_level = logical;
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET max_replication_slots = 10;

Starta om källdatabasen för att wal_level ändringen ska träda i kraft. På en hanterad tjänst, använd leverantörens parametergrupp eller flaggor för att sätta wal_level till logical. Till exempel, på Amazon Aurora PostgreSQL, ställ rds.logical_replication in till 1 i databasklustrets parametergrupp och starta om klustret. På Amazon RDS för PostgreSQL, sätt samma parameter i databasens parametergrupp och starta om instansen.

Skapa en roll för replikering och ge den läsåtkomst till de tabeller du replikerar:

CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD '<password>';
GRANT USAGE ON SCHEMA public TO replication_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO replication_user;

Denna CREATE ROLE sats fungerar som skriven på en självhanterad Postgres-server. Vissa hanterade Postgres-leverantörer tillåter inte attributet REPLICATION direkt utan ger istället replikeringsåtkomst via en leverantörsspecifik roll. Om din källa körs på en hanterad tjänst, följ leverantörens dokumentation för att ge rollen replikeringsåtkomst, och använd sedan den rollen istället för replication_user i de följande stegen. Till exempel, på Amazon Aurora PostgreSQL och Amazon RDS för PostgreSQL, skapa rollen utan WITH REPLICATION och kör GRANT rds_replication TO replication_usersedan .

Skapa en publikation för de tabeller du vill replikera. Varje tabell måste ha en PRIMARY KEY eller en replikidentitet inställd. Se Replica-identitet i Postgres-dokumentationen.

CREATE PUBLICATION my_publication FOR TABLE orders, customers;

Låt Lakebase nå källan

Som abonnent upprättar Lakebase en utgående anslutning till din källdatabas. Denna utgående anslutning styrs av ditt kontos nätverkspolicy, som styr de internetdestinationer som serverlösa arbetsbelastningar kan nå. Den styrs inte av en projektinställning för Lakebase eller en roll i databasen.

Om du behöver göra en ändring beror på om ditt konto tillämpar en nätverkspolicy:

  • Ingen aktiv nätverkspolicy: Lakebase kan nå vilken utgivare som helst som har en tillgänglig publik slutpunkt. Ingen ändring krävs.
  • En aktiv nätverkspolicy: lägg till källdatabasens värdnamn till de tillåtna internetdestinationerna i kontots nätverkspolicy. Se Hantera nätverksprinciper. Om värdnamnet inte är tillåtet avvisas prenumerationen när du skapar den. Se Felsökning.

Private Link stöds inte för abonnentanslutningen. Källdatabasen måste vara tillgänglig via sin publika endpoint.

Skapa måltabellerna

Logisk replikering kopierar data, inte schema. Skapa tabellerna i måldatabasen Lakebase med samma namn och kolumner som källdatabasen innan du börjar replikera. Du kan skapa dem manuellt, eller dumpa schemat från källan och ladda in det i Lakebase. Se Dumpa schemat endast.

Skapa måltabellerna tomma. Den initiala tabellkopian misslyckas vid dubblettnycklar eller begränsningsbrott om en måltabell redan innehåller rader.

Skapa prenumerationen

Anslut till måldatabasen Lakebase som en roll som kan skapa prenumerationer (se Förkunskaper) och skapa sedan en prenumeration som kopplas till källutgivaren:

CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=<source-host> port=5432 dbname=<source-db> user=replication_user password=<password> sslmode=verify-full sslrootcert=system'
PUBLICATION my_publication;

Att skapa prenumerationen startar en replikeringsslot på källutgivaren, kopierar de befintliga raderna och strömmar sedan pågående ändringar.

Warning

replikeringsslotten gör att källdatabasen behåller write-ahead log (WAL) tills Lakebase bekräftar att den har mottagit ändringarna. Om prenumerationen slutar konsumera ändringar, till exempel för att den är inaktiverad, avstängd eller misslyckas, ackumuleras WAL på källan utan begränsning. På en produktionskälla kan detta fylla källans lagringsutrymme och orsaka ett avbrott.

Medan replikationen körs, övervaka hur mycket WAL replikeringsslotten behåller på källan:

SELECT slot_name, active,
       pg_catalog.pg_size_pretty(pg_catalog.pg_wal_lsn_diff(pg_catalog.pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_catalog.pg_replication_slots;

För att begränsa risken på en självhanterad källa, ställ in max_slot_wal_keep_size för att begränsa hur mycket WAL en slot kan behålla. Om en slot överskrider gränsen ogiltigförklarar Postgres den och prenumerationen måste skapas på nytt. Avsluta prenumerationen så snart du är klar med migreringen. Se Replikationsplatser och lagring.

Note

När Lakebase ansluts kopplar den upp sig mot din källdatabas och skickar replikeringsrollens inloggningsuppgifter till den. sslmode=verify-full sslrootcert=system krypterar anslutningen och verifierar källans identitet, vilket skyddar de vidarebefordrade inloggningsuppgifterna mot en man-i-mitten-attack. Det fungerar när din källa använder en offentligt betrodd certifikatutfärdare. Den svagare sslmode=require krypterar men verifierar inte ursprunget. Det går inte att verifiera en källa som använder en privat certifikatutfärdare.

Kontrollera replikering

På måldatabasen Lakebase, bekräfta att de befintliga raderna har anlänt:

SELECT COUNT(*) FROM orders;

Infoga eller uppdatera en rad på källan och fråga sedan målet på nytt. Förändringen dyker upp på Lakebase inom några sekunder.

Övervaka och växla över

Följ den initiala kopian och pågående fördröjning:

SELECT subname, received_lsn, latest_end_lsn, last_msg_receipt_time
FROM pg_catalog.pg_stat_subscription;

För att bekräfta att den initiala kopian är klar, kör statusfrågan för synkronisering per tabell i Monitor-replikering på prenumeranten och vänta tills varje tabell visar Ready (fully live).

När målet har hunnit ikapp, stoppa skrivningar på källan, bekräfta att målet är fullt aktuellt och byt så att applikationen använder Lakebase-anslutningsuppgifterna.

Logisk replikation kopierar inte sekvensvärden eller identitetsräknare. Innan du återupptar skrivningar på Lakebase, återställ varje målsekvens för att matcha den replikerade datan, eller så kan nya insättningar i SERIAL eller identitetskolumner generera dubbletter av primärnycklar:

SELECT pg_catalog.setval(pg_catalog.pg_get_serial_sequence('orders', 'id'), (SELECT MAX(id) FROM orders));

När din applikation körs mot Lakebase, avsluta prenumerationen för att sluta replikera från källan. När källan är tillgänglig tar man också bort replikationssloten om prenumerationen avslutas. Se Ta bort en prenumeration eller publikation.

För övervakning och rensning, se Hantera och övervaka logisk replikation.

Nästa steg

  • Uppdaterades senast