Une fois qu'un déploiement SQL est en cours d'exécution, sa requête devient immuable. Pour modifier la logique de la requête, arrêtez le déploiement, mettez à jour le code SQL, puis redémarrez-le. Vous pouvez choisir de conserver ou non l'état, selon que la modification est compatible avec l'état existant.
Choisir une approche
Sélectionnez une approche en fonction de la compatibilité de votre modification SQL avec l'état :
|
Approche |
Cas d'utilisation |
|
Arrêt, mise à jour et redémarrage avec conservation de l'état |
La modification SQL est compatible avec l'état (consultez la section de référence sur la compatibilité des états ci-dessous) |
|
Arrêt, mise à jour et redémarrage sans conservation de l'état |
La modification SQL n'est pas compatible avec l'état, ou la perte de l'état est acceptable |
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Un déploiement dont l'état est Running
Les permissions nécessaires pour arrêter et démarrer le déploiement
(Obligatoire pour les redémarrages avec état) Un point de sauvegarde (savepoint) ou un point de contrôle (checkpoint) disponible pour le déploiement
Redémarrer avec conservation de l'état
Privilégiez cette méthode lorsque votre modification SQL est compatible avec l'état. Le job reprend à partir d'un point de sauvegarde sans retraiter les données historiques.
Sur la page Deployments, repérez le déploiement cible et cliquez sur Stop.
-
Dans la boîte de dialogue, sélectionnez Stop With Savepoint et confirmez.
AvertissementFlink restaure l'état des opérateurs à partir du point de sauvegarde, mais ne peut pas annuler les écritures déjà émises vers des systèmes externes. Si le job a continué à s'exécuter après la création du point de sauvegarde, le job redémarré risque de réémettre les mêmes enregistrements. La sécurité de cette opération dépend de votre connecteur de sortie (sink) :
Connecteurs de sortie idempotents (par exemple, des opérations upsert vers un magasin clé-valeur) : les écritures en double sont généralement sans conséquence.
Connecteurs de sortie en ajout seul (par exemple, un topic Kafka ou une table de base de données sans clé primaire) : les enregistrements en double sont écrits et ne peuvent pas être supprimés.
Une fois que le déploiement atteint l'état Stopped, cliquez sur Edit et mettez à jour le code SQL.
Cliquez sur Start. Dans la boîte de dialogue de démarrage, sélectionnez Resume Mode, définissez la source d'état sur Specific State et choisissez le point de sauvegarde créé à l'étape 2.
Vérifiez que le déploiement atteint l'état Running.
Redémarrer sans conservation de l'état
Optez pour cette approche si la modification SQL n'est pas compatible avec l'état, ou si un retraitement complet depuis le début est acceptable.
Sur la page Deployments, repérez le déploiement cible et cliquez sur Stop.
Attendez que le déploiement atteigne l'état Stopped.
Cliquez sur Edit et mettez à jour le code SQL.
Cliquez sur Start, puis sélectionnez Initial Mode pour démarrer depuis le début, ou configurez un décalage de source (offset) pour commencer à une position spécifique du flux de données amont.
Vérifiez que le déploiement atteint l'état Running.
Référence sur la compatibilité des états
La compatibilité des états détermine si la nouvelle requête peut reprendre à partir du point de sauvegarde du job précédent. Le tableau suivant récapitule les modifications compatibles avec un redémarrage conservant l'état.
|
Type de modification |
Compatible avec l'état ? |
Remarques |
|
Modification de la logique d'un opérateur sans état (par exemple, mise à jour d'une clause |
Oui |
Les opérateurs sans état ne conservent aucun état ; la modification n'affecte donc pas la compatibilité du point de sauvegarde. |
|
Ajout d'un opérateur sans état |
Oui |
Le nouvel opérateur s'initialise sans état, ce qui est valide. |
|
Suppression d'un opérateur sans état |
Oui |
Aucune perte d'état. |
|
Ajout d'un opérateur avec état (par exemple, une nouvelle agrégation ou jointure) |
Partiellement |
Le nouvel opérateur démarre avec son état initial par défaut. Les états des opérateurs existants sont préservés. |
|
Suppression d'un opérateur avec état |
Non — perte d'état |
L'état de l'opérateur supprimé est ignoré. S'il n'est pas absorbé par un autre opérateur, l'état est définitivement perdu. |
|
Modification du type de données de l'état d'un opérateur |
Non |
Flink ne peut pas désérialiser l'état existant vers un type différent. Réinitialisez l'état et retraitez les données. |
|
Modification de la clé d'une agrégation keyée |
Non |
L'état est organisé selon l'ancienne clé. Une clé différente génère une structure de partition d'état distincte. |
|
Remplacement d'un connecteur source ou sink |
Dépend |
Si le nouveau connecteur est compatible au niveau du schéma, les opérateurs en aval peuvent être préservés. Effectuez un test de déploiement avant de procéder. |
Attribuez des UID d'opérateur explicites à tous les opérateurs avec état dans vos déploiements SQL. Flink dérive les ID d'opérateur par défaut de la position de l'opérateur dans le graphe du job ; si vous modifiez la requête, les positions peuvent changer et les ID par défaut également, rendant impossible le redémarrage basé sur un point de sauvegarde. Avec des UID explicites, Flink peut associer de manière fiable l'état du point de sauvegarde aux opérateurs corrects, même après des modifications de la requête.
Étapes suivantes
Présentation des déploiements SQL
Gérer les points de sauvegarde
Surveiller l'état du déploiement