Dépréciation du protocole AMQP pour la diffusion en continu des événements de modification

Cet article décrit l’abandon du protocole AMQP pour la fonctionnalité de streaming des événements de modification (CES) dans SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance et la base de données SQL de Microsoft Fabric.

La dépréciation du protocole AMQP introduit une modification avec rupture de compatibilité de la valeur de configuration destination_type lors de la création de nouveaux groupes de flux. Le calendrier de déploiement varie selon le produit. Cet article explique comment ces changements affectent les groupes de flux nouveaux et existants, les différences spécifiques à chaque plateforme, et comment migrer les groupes de flux existants du protocole AMQP vers le protocole Kafka.

Qu’est-ce que le protocole AMQP ?

Le protocole AMQP (« AMQP ») était l’un des deux protocoles que CES supportait lors de l’envoi d’événements de changement vers Azure Event Hubs et Fabric Eventstream. C’était une implémentation service-à-service qui publiait des événements sur Azure Event Hubs et Fabric Eventstream.

Avant ce changement de rupture, vous avez spécifié le protocole dans la destination_type valeur de configuration lors de la configuration d’un groupe de flux, en utilisant l’une des valeurs suivantes prises en charge :

• AzureEventHubsAMQP - Protocole AMQP
• AzureEventHubsApacheKafka - Protocole Kafka

Après ce changement avec rupture de compatibilité, la seule valeur destination_type prise en charge pour les groupes de flux nouvellement créés sur Azure SQL Database et SQL database dans Microsoft Fabric est AzureEventHubs, qui utilise le protocole Kafka. Azure SQL Managed Instance et SQL Server 2025 acceptent toujours AzureEventHubsAMQP et AzureEventHubsApacheKafka.

Depuis le 15 août 2026, les groupes de flux nouvellement créés sur Azure SQL Database doivent utiliser AzureEventHubs comme le destination_type. Les tentatives de création d’un groupe de flux en utilisant des valeurs précédentes échouent.

Les consommateurs de messages publiés sur Azure Event Hubs peuvent choisir entre le protocole AMQP ou Kafka, quel que soit le protocole qui publie le message.

Support de la plateforme pour les valeurs destination_type

Les valeurs autorisées destination_type lors de la création d’un nouveau groupe de flux dépendent du produit et de la version :

Pour les nouveaux groupes de stream, utilisez AzureEventHubs lorsque la plateforme le supporte. Pour Azure SQL Managed Instance et SQL Server 2025, utilisez AzureEventHubsApacheKafka (protocole Kafka). Éviter AzureEventHubsAMQP pour les nouveaux groupes de flux.

Comment migrer des groupes de flux configurés AMQP vers Kafka

Les groupes CES existants configurés AzureEventHubsAMQP continuent de publier des messages en utilisant le protocole AMQP jusqu’en avril 2027. Recréez vos groupes de flux existants configurés avec AMQP dans SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance ou une base de données SQL dans Microsoft Fabric en utilisant AzureEventHubs comme destination_type dès que possible.

Utilisez la requête suivante pour identifier tous les groupes de flux configurés :

exec sp_help_change_event_stream_groups

Sauvegardez les valeurs de configuration pour les groupes de flux qui ont AzureEventHubsAMQP dans la colonne streaming_dest_type . Vous avez besoin de ces valeurs lors de la création des nouveaux groupes de stream.

Utilisez la requête suivante pour identifier les tables dans chaque groupe de flux que vous devez migrer :

exec sys.sp_help_change_event_stream_tables

Pour migrer un groupe de flux configuré AMQP vers Kafka, suivez ces étapes :

1. Créez un flux de remplacement en utilisant la procédure sys.sp_create_event_stream_group stockée. Spécifie AzureEventHubs comme destination_type paramètre.

   Le destination_location paramètre attend le port 9093, comme dans l’exemple suivant : myEventHubsNamespace.servicebus.windows.net:9093/myEventHubsInstance.

   Le protocole Kafka prend en charge l’authentification Microsoft Entra ou clé de service. L’authentification SAS n’est désormais plus disponible pour le CES.

2. Retirez chaque table, une par une, de l’ancien groupe de flux en utilisant 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. Ajoutez chaque tableau que vous avez retiré de l’ancien groupe de flux au nouveau groupe de flux de remplacement en utilisant 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. Une fois que vous avez ajouté toutes les tables au nouveau groupe de flux, utilisez sys.sp_drop_event_stream_group pour supprimer l’ancien groupe. Pour plus de détails, consultez configurer CES.

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

5. Vérifiez que le nouveau groupe de flux est actif en exécutant sp_help_change_event_stream_groups et en confirmant que AzureEventHubs s’affiche comme streaming_dest_type.

Répétez ce processus pour chaque groupe de flux configuré AMQP dans votre environnement.

Déplacer des tables vers de nouveaux groupes de flux (Kafka)

CES scanne et publie les modifications du fichier journal dès leur création, mais la latence de publication peut provoquer un lag des événements. Lorsque vous retirez une table d’un groupe de stream, les modifications en attente dans le fichier journal ne sont pas publiées. Ainsi, coordonnez soigneusement les tables mobiles entre les groupes de flux afin d’éviter de manquer des événements.

Avant de retirer une table d’un groupe de stream, vérifiez le DMV sys.dm_change_feed_log_scan_sessions pour vous assurer qu’il n’y a pas de modifications en attente à publier sur les tables. S’il y a des modifications en attente, attendez que le processus les publie avant de retirer la table de l’ancien groupe de flux et de l’ajouter au nouveau groupe.

Pour réduire le risque d’événements manquants, utilisez l’une des approches suivantes :

• Déplacez les tables entre groupes de flux pendant une fenêtre de maintenance dédiée lorsqu’aucune écriture n’est en cours sur les tables.
• Placez un verrou exclusif sur les tables en cours de streaming pendant une période de faible activité afin d’empêcher toute nouvelle écriture dans ces tables. Ne libérez le verrou exclusif qu’une fois que les tables sont dans le nouveau groupe de flux.

Chronologies de dépréciation

La dépréciation du protocole AMQP suit ces deux chronologies :

Les consommateurs de messages publiés n’ont pas besoin de faire de modifications.

Impact de la dépréciation

Cette section décrit l’impact de la dépréciation du protocole AMQP, par exemple :

• Impact sur les consommateurs des messages publiés
• Impact sur les groupes de flux AMQP existants
• Impact sur les nouveaux groupes de ruisseaux créés
• Impact sur la configuration du réseau des éditeurs

Impact sur les consommateurs des messages publiés

Le protocole utilisé pour écrire sur la destination (soit Azure Event Hubs ou Fabric Eventstream) est indépendant du protocole utilisé par les consommateurs de messages. Par conséquent, passer du protocole AMQP au protocole Kafka pour la publication de messages n’affecte pas les consommateurs de messages. Ils peuvent continuer à consommer des messages en utilisant l’un ou l’autre protocole.

Impact sur les groupes de flux AMQP existants

Les groupes de flux existants configurés AzureEventHubsAMQPcontinuent de fonctionner tels quels en utilisant le protocole AMQP. Il n’y a pas d’interruption immédiate ni de changement de configuration nécessaire pour ces groupes. Cependant, vous devez migrer des groupes de flux configurés AMQP pour utiliser le protocole Kafka avant la suppression du support du protocole AMQP en avril 2027.

Impact sur les nouveaux groupes de ruisseaux créés

À partir du 15 août 2026, la seule valeur autorisée destination_type pour les nouveaux groupes de flux créés sur Azure SQL Database et SQL Database dans Microsoft Fabric est AzureEventHubs. Les tentatives de création d’un groupe de flux en utilisant soit une valeur précédente, AzureEventHubsAMQP soit AzureEventHubsApacheKafka, échouent avec le message d’erreur suivant :

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.'

Mettez à jour tous les scripts d’automatisation qui créent des groupes de flux avant cette date. Le destination_type paramètre doit utiliser AzureEventHubs au lieu de AzureEventHubsAMQP ou AzureEventHubsApacheKafka.

Le protocole Kafka utilise Microsoft Entra ou authentification par clé de service pour se connecter à Azure Event Hubs ou Fabric Eventstream. Si vos groupes de flux AMQP existants utilisent l’authentification SAS, vous devez passer soit à Microsoft Entra, soit à l’authentification par clé de service lors de la création de nouveaux groupes de flux. Voir Configurer le flux d’événements de changement pour plus de détails sur la façon de configurer l’authentification des groupes de flux.

Impact sur la configuration du réseau des éditeurs

Selon la configuration du réseau côté publication, il se peut que vous deviez reconfigurer les ports sortants autorisés pour utiliser le port 9093 de Kafka, au lieu des ports 5671 et 5672 utilisés par AMQP. L’éditeur doit autoriser le trafic sortant sur le port 9093.

Ne laissez les ports 5671 et 5672 ouverts que si vous avez des groupes de flux existants qui utilisent encore le protocole AMQP. Ces ports ne sont pas nécessaires pour les groupes de flux nouvellement créés utilisant le protocole Kafka.

Pour plus d’informations, voir la configuration du pare-feu par protocole Azure Event Hubs.

Contenu connexe

• Qu’est-ce que la diffusion en continu des événements de modification (préversion) ?
• Configurez le streaming des événements de modification (aperçu) vers Azure Event Hubs
• Format de message JSON - Modifier le streaming d’événements
• FAQ sur le changement d’événements en streaming
• sys.dm_change_feed_log_scan_sessions (Transact-SQL)
• Configuration du pare-feu d’Azure Event Hubs par protocole