Wycofanie protokołu AMQP dla strumieniowania zdarzeń zmian

Ten artykuł opisuje wycofanie protokołu AMQP z funkcji change event streaming (CES) w SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance oraz bazie danych SQL w Microsoft Fabric.

Wycofanie protokołu AMQP wprowadza niekompatybilną zmianę dotyczącą wartości konfiguracji destination_type podczas tworzenia nowych grup strumieni. Harmonogram wdrożenia różni się w zależności od produktu. Ten artykuł wyjaśnia, jak te zmiany wpływają na nowe i istniejące grupy strumieniowe, różnice specyficzne dla poszczególnych platform oraz jak migrować istniejące grupy strumieniowe z protokołu AMQP do protokołu Kafki.

Czym jest protokół AMQP?

Protokół AMQP ("AMQP") był jednym z dwóch protokołów, które CES wspierał podczas wysyłania zdarzeń zmian do Azure Event Hubs i Fabric Eventstream. Była to implementacja service-to-service, która publikowała zdarzenia dla Azure Event Hubs i Fabric Eventstream.

Przed tą przełomową zmianą określiłeś protokół w destination_type wartości konfiguracji podczas konfiguracji grupy strumieni, używając jednej z następujących obsługiwanych wartości:

• AzureEventHubsAMQP - Protokół AMQP
• AzureEventHubsApacheKafka - Protokół Kafki

Po tej przełomowej zmianie jedyną obsługiwaną destination_type wartością dla nowo utworzonych grup strumieni w Azure SQL Database i SQL w Microsoft Fabric AzureEventHubsjest , która korzysta z protokołu Kafka. Azure SQL Managed Instance i SQL Server 2025 nadal akceptują AzureEventHubsAMQP i AzureEventHubsApacheKafka.

Od 15 sierpnia 2026 r. nowo utworzone grupy strumieni w usłudze Azure SQL Database muszą używać AzureEventHubs jako destination_type. Próby utworzenia grupy strumieniowej z użyciem wcześniejszych wartości nie powiodą się.

Konsumenci wiadomości publikowanych w Azure Event Hubs mogą wybrać między protokołem AMQP a Kafka, niezależnie od protokołu, który publikuje wiadomość.

Obsługa platformy dla wartości destination_type

Dozwolone destination_type wartości przy tworzeniu nowej grupy strumieni zależą od produktu i wersji:

W przypadku nowych grup strumieni używaj AzureEventHubs, jeśli platforma to obsługuje. W przypadku usługi Azure SQL Managed Instance i programu SQL Server 2025 użyj AzureEventHubsApacheKafka (protokół Kafka). Unikaj AzureEventHubsAMQP w przypadku nowych grup strumieni.

Jak migrować grupy strumieniowe skonfigurowane przez AMQP do Kafki

Istniejące grupy CES skonfigurowane przy użyciu AzureEventHubsAMQP będą nadal publikować komunikaty przy użyciu protokołu AMQP do kwietnia 2027 r. Odtwórz istniejące grupy strumieni skonfigurowane za pomocą protokołu AMQP w programie SQL Server 2025, usłudze Azure SQL Database, usłudze Azure SQL Managed Instance lub w bazie danych SQL w Microsoft Fabric, używając AzureEventHubs jako destination_type, tak szybko, jak to możliwe.

Użyj następującego zapytania, aby zidentyfikować wszystkie skonfigurowane grupy strumieni:

exec sp_help_change_event_stream_groups

Zapisz wartości konfiguracyjne dla grup strumieni, które mają wartość AzureEventHubsAMQP w kolumnie streaming_dest_type. Potrzebujesz tych wartości przy tworzeniu nowych grup strumieni.

Użyj poniższego zapytania, aby zidentyfikować tabele w każdej grupie strumieni, które musisz przenieść:

exec sys.sp_help_change_event_stream_tables

Aby przenieść grupę strumieni skonfigurowaną przez AMQP do Kafki, należy wykonać następujące kroki:

1. Utwórz zastępczy strumień za pomocą procedury składowanej sys.sp_create_event_stream_group. Określ AzureEventHubs jako parametr.destination_type

   Parametr destination_location oczekuje portu 9093, na przykład w następującym przykładzie: myEventHubsNamespace.servicebus.windows.net:9093/myEventHubsInstance.

   Protokół Kafka obsługuje uwierzytelnianie Microsoft Entra lub klucza usługowego. Uwierzytelnianie SAS jest obecnie niedostępne dla CES.

2. Usuń każdą tabelę, pojedynczo, ze starej grupy strumieniowej, używając sys.sp_remove_object_from_event_stream_group:

   exec sys.sp_remove_object_from_event_stream_group @stream_group_name = '<old_stream_group_name>', @object_name = '<schema.table_name>'
   

3. Dodaj każdą tabelę, którą usunąłeś ze starej grupy strumieniowej, do nowej grupy strumieniowej zastępczej, używając sys.sp_add_object_to_event_stream_group:

   exec sys.sp_add_object_to_event_stream_group @stream_group_name = '<new_stream_group_name>', @object_name = '<schema.table_name>'
   

4. Gdy dodasz wszystkie tabele do nowej grupy strumieni, użyj sys.sp_drop_event_stream_group , aby usunąć starą grupę strumieni. Aby uzyskać szczegółowe informacje, zobacz konfigurowanie CES.

   exec sys.sp_drop_event_stream_group @stream_group_name = '<old_stream_group_name>'
   

5. Sprawdź, czy nowa grupa strumieni jest aktywna, uruchamiając sp_help_change_event_stream_groups i potwierdzając, że jako streaming_dest_type wyświetla się AzureEventHubs.

Powtórz ten proces dla każdej grupy strumieniowej skonfigurowanej przez AMQP w swoim środowisku.

Przenoszenie tabel do nowych grup strumieni (Kafka)

CES skanuje i publikuje zmiany w pliku logu w momencie ich utworzenia, ale opóźnienia publikowania mogą powodować opóźnienia zdarzeń. Gdy usuwasz tabelę z grupy strumieni, oczekujące zmiany w pliku logu nie są publikowane. Dlatego należy starannie koordynować przenoszenie tabel między grupami strumieni, aby nie pominąć zdarzeń.

Przed usunięciem tabeli z grupy strumieni sprawdź w DMV sys.dm_change_feed_log_scan_sessions , aby upewnić się, że nie ma żadnych oczekujących zmian do publikacji w tabelach. Jeśli są oczekujące zmiany, poczekaj, aż proces je opublikuje, zanim usuniesz tabelę ze starej grupy strumieni i dodasz ją do nowej grupy strumieni.

Aby zmniejszyć ryzyko przegapienia zdarzeń, zastosuj jedno z następujących podejść:

• Przenoś tabele między grupami strumieni podczas wydzielonego okna serwisowego, gdy do tabel nie są wykonywane żadne operacje zapisu.
• Wprowadź wyłączną blokadę na tabele przesyłane strumieniowo w okresie niskiej aktywności, aby zapobiec nowym zapisom do tych tabel. Wyłączną blokadę zwalniaj dopiero po tym, jak stoły są w nowej grupie streamów.

Harmonogramy wycofania

Wycofanie protokołu AMQP przebiega według następujących dwóch osi czasu:

Konsumenci publikowanych wiadomości nie muszą wprowadzać żadnych zmian.

Skutki wycofania z użycia

Ta sekcja opisuje wpływ wycofania protokołu AMQP, na przykład:

• Wpływ publikowanych wiadomości na konsumentów
• Wpływ na istniejące grupy strumieniowe AMQP
• Wpływ na nowo utworzone grupy strumieni
• Wpływ na konfigurację sieci wydawców

Wpływ publikowanych wiadomości na konsumentów

Protokół używany do zapisu do miejsca docelowego (Azure Event Hubs lub Fabric Eventstream) jest niezależny od protokołu używanego przez odbiorców wiadomości. Dlatego przejście z protokołu AMQP na Kafka do publikowania wiadomości nie wpływa na odbiorców wiadomości. Mogą one nadal konsumować wiadomości za pomocą dowolnego protokołu.

Wpływ na istniejące grupy strumieniowe AMQP

Istniejące grupy strumieni skonfigurowane za pomocą AzureEventHubsAMQPnadal działają bez zmian przy użyciu protokołu AMQP. Nie ma potrzeby natychmiastowego zakłócania ani zmiany konfiguracji dla tych grup. Jednak musisz migrować grupy strumieniowe skonfigurowane przez AMQP, aby korzystały z protokołu Kafka, zanim wsparcie dla protokołu AMQP zostanie usunięte w kwietniu 2027 roku.

Wpływ na nowo utworzone grupy strumieni

Od 15 sierpnia 2026 r. jedyną dozwoloną wartością parametru destination_type dla nowo tworzonych grup strumieni w usłudze Azure SQL Database oraz baz danych SQL w usłudze Microsoft Fabric jest AzureEventHubs. Próby utworzenia grupy strumieni przy użyciu poprzedniej wartości AzureEventHubsAMQP lub AzureEventHubsApacheKafka, kończy się niepowodzeniem z następującym komunikatem o błędzie:

Msg 23626, Level 16, State 2, Line 481, An error occurred. The error/state returned was 23618/5: 'The value provided for the argument '@destination_type' is invalid. Allowed values: AzureEventHubs.'

Zaktualizuj przed tą datą wszelkie skrypty do automatyzacji, które tworzą grupy strumieni. Parametr destination_type musi używać AzureEventHubs zamiast AzureEventHubsAMQP lub AzureEventHubsApacheKafka.

Protokół Kafka wykorzystuje Microsoft Entra lub uwierzytelnianie za pomocą klucza usługi do łączenia z usługami Azure Event Hubs lub Fabric Eventstream. Jeśli twoje istniejące grupy strumieniowe AMQP używają uwierzytelniania SAS, musisz przejść na Microsoft Entra lub uwierzytelnianie kluczem serwisowym przy tworzeniu nowych grup strumieniowych. Zobacz Konfigurowanie strumieniowania zdarzeń zmian, aby dowiedzieć się, jak skonfigurować uwierzytelnianie dla grup strumieni.

Wpływ na konfigurację sieci wydawców

W zależności od konfiguracji sieci po stronie publikującej, może być konieczne przekonfigurowanie dozwolonych portów wychodzących na port 9093 Kafki, zamiast portów 5671 i 5672 używanych przez AMQP. Wydawca musi umożliwić ruch wychodzący na porcie 9093.

Porty 5671 i 5672 zostaw otwarte tylko wtedy, gdy istnieją grupy strumieniowe, które nadal używają protokołu AMQP. Te porty nie są wymagane dla nowo utworzonych grup strumieniowych korzystających z protokołu Kafka.

Więcej informacji można znaleźć w artykule Konfiguracja zapory Azure Event Hubs dla każdego protokołu.

Treści powiązane

• Co to jest przesyłanie strumieniowe zdarzeń zmian (wersja zapoznawcza)?
• Konfigurowanie przesyłania strumieniowego zdarzeń zmian (wersja zapoznawcza) w usłudze Azure Event Hubs
• Format komunikatów JSON — zmienianie przesyłania strumieniowego zdarzeń
• FAQ dotyczące streamingu zdarzenia zmiany
• sys.dm_change_feed_log_scan_sessions (Transact-SQL)
• Konfiguracja zapory Azure Event Hubs dla każdego protokołu