Ograniczenia łącznika bazy danych PostgreSQL

Ta strona zawiera listę ograniczeń i zagadnień dotyczących pozyskiwania bazy danych PostgreSQL przy użyciu usługi Databricks Lakeflow Connect.

Ogólne ograniczenia łącznika bazy danych

Ograniczenia w tej sekcji dotyczą wszystkich łączników bazy danych w programie Lakeflow Connect. Kontynuuj odczytywanie ograniczeń specyficznych dla łącznika.

• Po uruchomieniu zaplanowanego potoku alerty nie są wyzwalane od razu. Zamiast tego wyzwalają się po uruchomieniu następnej aktualizacji.
• Po usunięciu tabeli źródłowej tabela docelowa nie zostanie automatycznie usunięta. Musisz ręcznie usunąć tabelę docelową. To zachowanie nie jest zgodne z działaniem Spark Declarative Pipelines w Lakeflow.
• Katalog przejściowy nie może być katalogiem obcym.
• W okresach konserwacji źródła usługa Databricks może nie mieć dostępu do Twoich danych.
• Jeśli nazwa tabeli źródłowej powoduje konflikt z istniejącą nazwą tabeli docelowej, aktualizacja procesów zakończy się niepowodzeniem.
• Obsługiwanie potoków z wieloma miejscami docelowymi jest dostępne wyłącznie przez API.
• Możesz zmienić nazwę tabeli, którą importujesz. Jeśli zmienisz nazwę tabeli w swoim potoku, stanie się on potokiem dostępnym tylko przez API, i nie będzie można już edytować potoku w interfejsie użytkownika.
• Jeśli wybierzesz kolumnę po uruchomieniu potoku, łącznik nie wypełnia automatycznie danych dla nowej kolumny. Aby pozyskać dane historyczne, ręcznie przeprowadź pełne odświeżanie na tabeli.
• Usługa Databricks nie może pozyskiwać co najmniej dwóch tabel o tej samej nazwie w tym samym potoku, nawet jeśli pochodzą one z różnych schematów źródłowych.
• System źródłowy zakłada, że kolumny kursorów są monotonicznie rosnące.
• Łącznik pozyskuje nieprzetworzone dane bez przekształceń. Użyj dalszych deklaratywnych potoków Spark w potokach Lakeflow do przekształceń.

• Łącznik obsługuje tylko replikację z podstawowych wystąpień bazy danych PostgreSQL.

Authentication

• Łącznik obsługuje tylko uwierzytelnianie nazwy użytkownika i hasła.

Odmiany bazy danych

• Łącznik obsługuje program PostgreSQL 13 lub nowszy.
• Łącznik obsługuje usługi AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database for PostgreSQL, maszyny wirtualne platformy Azure i GCP Cloud SQL for PostgreSQL. Łącznik obsługuje również lokalną usługę PostgreSQL przy użyciu usług Azure ExpressRoute, AWS Direct Connect i sieci VPN. Aby uzyskać szczegółowe informacje na temat łączności między chmurami, zobacz Łączność sieciowa.

Pipelines

• Każdy potok pozyskiwania musi być skojarzony z dokładnie jedną bramą pozyskiwania. Bramy nie mogą być współdzielone w ramach potoków.
• Mimo że potok pozyskiwania działa w bezserwerowej infrastrukturze komputerowej, brama pozyskiwania musi działać na klasycznej infrastrukturze komputerowej.
• Brama pozyskiwania musi działać w trybie ciągłym, aby zapobiec narastaniu dziennika zapisu z wyprzedzeniem (WAL) i akumulowaniu gniazd replikacji.

Replication

• Replikacja logiczna wymaga bazy danych PostgreSQL 13 lub nowszego z parametrem wal_level ustawionym na wartość logical.

• Każda replikowana tabela musi mieć tożsamość repliki ustawioną na FULL lub DEFAULT. Usługa Databricks zaleca używanie FULL tożsamości repliki dla tabel bez kluczy podstawowych lub z kolumnami TOASTable.
• Miejsca replikacji nie są usuwane automatycznie podczas usuwania potoków. Aby zapobiec akumulowaniu pliku WAL, należy ręcznie wyczyścić miejsca replikacji. Zobacz Czyszczenie miejsc replikacji.
• Konektor używa pozycji slotu replikacji do tworzenia punktów kontrolnych. Jeśli podstawowy węzeł PostgreSQL zostanie zdegradowany lub zastąpiony (na przykład podczas pracy w trybie failover), informacje o miejscu replikacji zostaną utracone. Powoduje to wystąpienie błędu „slot not found”, który wymaga pełnego odświeżenia wszystkich tabel w potoku danych. Nawiązywanie połączenia z innym węzłem źródłowym nie jest obsługiwane.

Ewolucja schematu

Zachowania opisane w tej sekcji obowiązują tylko wtedy, gdy włączysz DDL inline. W przypadku wyłączenia wbudowanego języka DDL łącznik nadal wykrywa zmiany schematu, ale tabele, których dotyczy problem, wymagają pełnego odświeżania. Aby włączyć DDL w tekście, zobacz Opcjonalnie: skonfiguruj śledzenie DDL w tekście.

Po włączeniu wbudowanej obsługi DDL łącznik automatycznie obsługuje dodawanie i usuwanie kolumn.

• Gdy w źródle pojawi się nowa kolumna, łącznik automatycznie zaimportuje ją przy kolejnym uruchomieniu potoku.
• Po usunięciu kolumny ze źródła łącznik nie usuwa go automatycznie. Zamiast tego łącznik używa właściwości tabeli, aby ustawić usuniętą kolumnę na inactive w obiekcie docelowym. Jeśli później zostanie wyświetlona inna kolumna z nazwą, która powoduje konflikt z kolumną inactive , potok zakończy się niepowodzeniem. W takim przypadku uruchom pełne odświeżenie tabeli lub ręcznie upuść nieaktywną kolumnę.

Łącznik może obsługiwać następujące instrukcje DDL, ale wymaga pełnego odświeżenia tabel docelowych.

Instrukcje DDL wymagające pełnego odświeżenia

• Zmienianie typu danych kolumny
• Zmiana nazwy kolumny
• Zmienianie klucza podstawowego tabeli
• Przekształcanie tabeli z niezarejestrowanej na zarejestrowaną lub odwrotnie
• Dodawanie lub usuwanie partycji (dla tabel partycjonowanych)

Staging

Katalog testowy nie może być katalogiem obcym.

Tables

• Usługa Databricks zaleca pozyskiwanie 250 lub mniej tabel na jeden przepływ danych. Nie ma jednak limitu liczby wierszy lub kolumn obsługiwanych w tych tabelach.
• Usługa Databricks nie może pozyskiwać dwóch tabel, których nazwy różnią się tylko wielkością liter (na przykład mytable i MyTable), w jednym potoku. Aby obsługiwać takie przypadki, utwórz dwie pary potoków bramy i pobierania, które publikują do różnych schematów docelowych.
• Nazwy source_catalog, source_schema, i source_table są rozróżniane ze względu na wielkość liter dla nazwy bazy danych, ale ignorują wielkość liter dla nazw schematów i tabel (zgodnie z domyślnym zachowaniem PostgreSQL). Jeśli na przykład źródłowa baza danych nosi nazwę MyDatabase, musisz określić ją jako MyDatabase w pliku ingestion_definition.
• Chociaż w jednym potoku można pozyskiwać dane z wielu źródłowych baz danych lub schematów, nie można pozyskiwać dwóch tabel o tej samej nazwie. Na przykład nie można przetwarzać zarówno schema1.orders, jak i schema2.orders w tym samym potoku.
• Możesz uwzględnić wiele specyfikacji tabeli lub schematu w polu objectsingestion_definition. Jednak nazwy tabel źródłowych w różnych schematach źródłowych nie mogą się nakładać. Nakładające się nazwy powodują niepowodzenie potoku pozyskiwania.

Typy danych

• Typy zdefiniowane przez użytkownika i typy rozszerzeń innych firm są przyjmowane jako ciągi znaków.
• Typy danych TIME i TIMETZ są traktowane jako ciągi znaków.
• Typy danych NUMERIC i DECIMAL:
  • Jeśli precyzja jest 38 lub mniejsza, NaN jest mapowana na wartość null.
  • Jeśli precyzja jest większa niż 38, wartość jest przechowywana jako ciąg i NaN jest zachowywana jako ciąg.
  • Inf i -Inf są obsługiwane tylko dla niezwiązanych typów liczbowych. W przypadku dokładności większej niż 38 wartość jest przechowywana jako ciąg, a wartość nieskończoności jest zachowywana.
• W przypadku DATE typu danych: obsługiwany jest pełny zakres dat PostgreSQL. Inf i -Inf są konwertowane na null. Daty BC są przechowywane przy użyciu astronomicznego numerowania roku. Na przykład 1 p.n.e. odpowiada rokowi 0 i 2 p.n.e. odpowiada -1.
• W przypadku TIMESTAMP typu danych (bez strefy czasowej) wartości są pozyskiwane jako ciągi. Inf i -Inf są zachowywane jako ciągi.
• W przypadku TIMESTAMP WITH TIME ZONE typu danych: obsługiwany zakres PostgreSQL to 4713-01-01 00:00:00.000000 BC do 294276-12-31 23:59:59.999999 AD, natomiast zakres obsługiwany przez usługę Databricks to -290308-12-21 BCE 19:59:06 GMT do +294247-01-10 CE 04:00:54 GMT. Znaczniki czasu powyżej maksymalnego obsługiwanego znacznika czasowego usługi Databricks są konwertowane na null. Daty BC są przechowywane przy użyciu astronomicznego numerowania roku. Na przykład 1 p.n.e. odpowiada rokowi 0 i 2 p.n.e. odpowiada -1. Inf i -Inf są konwertowane na null.
• Dla INTERVAL typu danych: Wartości nieskończoności są mapowane na 0 years 0 mins 0 days 0 hours 0 mins 0.0 secs.
• MONEY wartości są importowane jako ciągi znaków.
• Kolumny binarne (na przykład BYTEA) nie mogą być używane jako klucze klastrowania.
• Każdy wbudowany typ danych PostgreSQL nie wymieniony w tabeli Automatyczne przekształcenia danych jest pozyskiwany jako ciąg.

Tabele partycjonowane

• Obsługiwane są tabele partycjonowane bazy danych PostgreSQL.
• Każda partycja jest traktowana jako oddzielna tabela na potrzeby replikacji.
• Dodawanie lub usuwanie partycji wymaga pełnego odświeżenia tabeli.

Ograniczenia dotyczące określonych odmian bazy danych PostgreSQL

Amazon RDS i Aurora

• Parametr rds.logical_replication musi być ustawiony na 1.

Azure Database for PostgreSQL

• Replikacja logiczna musi być włączona w parametrach serwera.
• W przypadku wdrożeń pojedynczego serwera replikacja logiczna jest dostępna tylko w warstwach Ogólne przeznaczenie i Zoptymalizowane pod kątem pamięci.
• W przypadku wdrożeń serwera elastycznego replikacja logiczna jest obsługiwana we wszystkich warstwach.
• Parametr max_slot_wal_keep_size jest tylko do odczytu, stały w -1 (nieskończony) i nie można go skonfigurować.

Google Cloud SQL for PostgreSQL

• Flaga cloudsql.logical_decoding musi być włączona.
• Usługa Cloud SQL nie zezwala na konfigurowanie max_slot_wal_keep_size; jest ona domyślnie stała na -1 (nieskończona).