Replikuj dane z Lakebase

Ten przewodnik pokazuje, jak publikować zmiany z bazy danych Lakebase do zewnętrznego subskrybenta Postgresa za pomocą replikacji logicznej. Lakebase pełni rolę wydawcy: definiuje publikację, a zewnętrzny subskrybent łączy się, aby odbierać zmiany.

Warunki wstępne

  • Projekt Lakebase z bazą danych, z której chcesz publikować, zawierającą tabele, które chcesz opublikować.
  • Rola Lakebase Postgres, która jest członkiem roli databricks_superuser, na przykład rola właściciela projektu, aby utworzyć publikację. Aby przyznać databricks_superuser innej roli, zobacz: Utwórz role Postgres lub Aktualizuj rolę. To jest rola, jako którą się łączysz, a nie rola, której używa subskrybent. Tworzysz rolę replikacji subskrybenta w pierwszym kroku.
  • Połączenia chronione hasłem włączone w projekcie. Subskrybent łączy się z natywną rolą haseł Postgres, a połączenia z hasłami są domyślnie wyłączone dla nowych projektów. Zobacz Zarządzanie połączeniami haseł.
  • Zewnętrzna baza danych Postgres, która działa jako subskrybent. Subskrybent może być także bazą danych Lakebase w innym regionie. Replikacja między bazami Lakebase w tym samym regionie nie jest obsługiwana.

Replikacja logiczna jest obsługiwana w Lakebase i domyślnie działa z ustawieniem wal_level = logical, więc nie ma osobnego etapu włączania publikowania dla każdego projektu.

Stwórz rolę replikacyjną

Stwórz dedykowaną rolę dla zewnętrznego abonenta, aby łączyć się jako ta rola. Subskrybent łączy się za pomocą nazwy użytkownika i hasła Postgres, więc stwórz natywną rolę Postgres z hasłem, a nie rolę OAuth. Role OAuth są uwierzytelniane za pomocą krótkotrwałych tokenów Azure Databricks, których nie może użyć ciąg połączenia subskrypcji oparty na haśle. Rola musi mieć atrybut REPLICATION. Role, które tworzysz w aplikacji Lakebase, CLI lub API, mają ten atrybut, niezależnie od tego, czy im databricks_superuser nadajesz, czy nie. W aplikacji Lakebase na karcie Dodaj rolę>Hasło wpisz nazwę roli. Nie musisz wybierać databricks_superuser. Zobacz Tworzenie natywnej roli hasła Postgres.

Aby samodzielnie ustawić hasło, zamiast tego utwórz rolę za pomocą SQL. Uwzględnij REPLICATION atrybut, ponieważ role utworzone w SQL nie otrzymują go automatycznie:

CREATE ROLE replication_user WITH LOGIN REPLICATION PASSWORD '<password>';

Jeśli rola nie jest właścicielem tabel, które replikujesz, przyznaj jej dostęp do odczytu:

GRANT USAGE ON SCHEMA public TO replication_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO replication_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO replication_user;

Stwórz publikację

Połącz się z bazą danych Lakebase jako członek roli databricks_superuser , a następnie stwórz publikację dla tabel, które chcesz replikować. Każda tabela musi mieć PRIMARY KEY lub ustawioną tożsamość repliki. Zobacz tożsamość repliki w dokumentacji Postgres.

CREATE PUBLICATION my_publication FOR TABLE orders, customers;

Zezwól abonentowi się połączyć

Zewnętrzny subskrybent łączy się z Lakebase przez brzegowy serwer proxy usługi Azure Databricks, który wymusza listę dostępu IP w przestrzeni roboczej. Zezwól na adres IP subskrybenta na liście dostępu IP przestrzeni roboczej, aby mógł uzyskać dostęp do bazy danych Lakebase. Zobacz Zarządzanie listą dostępu IP.

Private Link nie jest obsługiwany dla połączenia subskrybenta. Subskrybent łączy się przez publiczny punkt końcowy Lakebase.

Subskrybuj zewnętrzną bazę danych

W zewnętrznej bazie Postgres stwórz docelowe tabele o tych samych nazwach i kolumnach co tabele, które publikujesz. Stwórz je puste: początkowa kopia zawodzi z powodu duplikatów kluczy lub naruszeń ograniczeń, jeśli docelowa tabela zawiera już wiersze. Możesz tworzyć tabele ręcznie albo zrzucić schemat z Lakebase i załadować go do subskrybenta. Zobacz Zrzuć tylko schemat.

Następnie, jako rola, która może tworzyć subskrypcje w zewnętrznej bazie danych, tworz subskrypcję łączącą się z Lakebase:

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

Użyj bezpośredniego połączenia dla subskrybenta. Replikacja logiczna wymaga trwałego połączenia, więc <lakebase-host> musi być bezpośrednią nazwą hosta punktu końcowego, a nie nazwą hosta puli połączeń -pooler. Zobacz pulę połączeń.

Note

Lakebase wymusza TLS na wszystkich połączeniach, więc ruch jest zawsze szyfrowany bez potrzeby działania. Aby uzyskać najsilniejszą ochronę, połącz się z sslmode=verify-full, który również weryfikuje certyfikat serwera Lakebase względem głównego magazynu certyfikatów Twojego systemu. Lakebase używa publicznie zaufanego certyfikatu, więc nie jest potrzebny dodatkowy certyfikat. Słabszy sslmode=require szyfruje, ale nie uwierzytelnia serwera.

Zweryfikuj replikację

Na zewnętrznym subskrybencie potwierdź, że dotarły istniejące wiersze:

SELECT COUNT(*) FROM orders;

Wstaw lub zaktualizuj wiersz w Lakebase, a następnie ponownie odpytaj subskrybent. Zmiana pojawia się u abonenta w ciągu kilku sekund.

Sprawdź status subskrypcji i opóźnienia u subskrybencie:

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

Aby potwierdzić, że początkowa kopia się zakończyła, uruchom zapytanie o status synchronizacji dla poszczególnych tabel w Monitorze replikacji na subskrybentie i poczekaj, aż każda tabela odczyta Ready (fully live).

Połączenie abonenta utrzymuje slot replikacyjny na wydawcy Lakebase. Gdy subskrybent aktywnie replikuje, zasoby obliczeniowe Lakebase nie są skalowane do zera. Zobacz Replikacja logiczna i skalowanie do zera. Jeśli subskrybent przestanie odbierać zmiany, slot staje się nieaktywny, a Lakebase usuwa go po około 40 godzinach. Zobacz Automatyczne usuwanie nieaktywnych slotów.

Następne kroki

  • Ostatnia aktualizacja o