Openflow Connector for MySQL : Maintenance¶

Note

Ce connecteur est soumis aux conditions d’utilisation de Snowflake Connector.

Cette rubrique décrit les considérations importantes en matière de maintenance et les bonnes pratiques pour la maintenance de Openflow Connector for MySQL, telles que la réinstallation du connecteur ou la configuration de la position de départ du journal binaire pour le chargement.

Ces opérations sont souvent utilisées conjointement avec la réplication incrémentielle avec instantanés.

Réinstaller le connecteur¶

Cette rubrique fournit des instructions sur la manière de réinstaller le connecteur et de continuer à répliquer les données pour les mêmes tables sans avoir à créer de nouveaux instantanés de celles-ci. Elle couvre les situations où le nouveau connecteur est installé dans le même environnement d’exécution, ainsi que déplacé vers un nouvel environnement d’exécution.

Avertissement

Pour que le connecteur continue la réplication à partir de la même position du flux CDC où il s’est arrêté avant la réinstallation, la base de données source doit conserver le journal binaire suffisamment longtemps pour couvrir la période écoulée entre l’arrêt du connecteur précédent et le démarrage du nouveau connecteur. Assurez-vous que le paramètre binlog_expire_logs_seconds du serveur MySQL est suffisamment élevé, et réduisez le temps de réinstallation au minimum.

La valeur de binlog_expire_logs_seconds doit être supérieure au temps prévu pour réinstaller le connecteur. En règle générale, 86 400 secondes (soit une journée) suffisent, mais des délais plus longs peuvent être appropriés pour assurer le temps nécessaire à la réinstallation.

Conditions préalables¶

Examinez et notez les valeurs contextuelles des paramètres du connecteur. Si vous réinstallez le connecteur dans le même environnement d’exécution, vous pouvez réutiliser le contexte existant. Si la nouvelle instance se trouve dans un environnement d’exécution différent, vous devez saisir à nouveau tous les paramètres.

Terminez le traitement de tous les FlowFiles en cours dans le connecteur existant, puis arrêtez le connecteur.
1. Connectez-vous à Snowsight.
2. Dans le menu de navigation, sélectionnez Ingestion » Openflow.
3. Dans le volet Openflow, sélectionnez l’onglet Runtimes.
4. Sélectionnez l’environnement d’exécution contenant le connecteur.
5. Sélectionnez le connecteur.
6. Arrêtez le processeur le plus élevé Set Tables for Replication dans le groupe Snapshot Load.
7. Arrêtez le processeur le plus élevé Read MySQL CDC Stream dans le groupe Incremental Load.
8. Si vous avez modifié la valeur du paramètre Merge Task Schedule CRON, rétablissez-le sur * * * * * ?. Sinon, les files d’attente ne seront pas vidées avant la prochaine exécution planifiée.
  
  Attendez que tous les FlowFiles du connecteur aient été traités et que toutes les files d’attente soient vides. Lorsque tous les FlowFiles ont été traités, la valeur Queued sur le groupe de processeurs du connecteur devient nulle. S’il reste des éléments dans les files d’attente du connecteur d’origine, il se peut qu’il y ait des écarts de données au démarrage du nouveau connecteur.
9. Arrêtez tous les processeurs et tous les services de contrôleur dans le connecteur.
Prudence

Le connecteur existant peut rester dans l’environnement d’exécution et n’interfère pas avec la nouvelle instance, tant qu’il reste à l’arrêt.
Créez une nouvelle instance du connecteur. Si vous utilisez le même environnement d’exécution que le connecteur d’origine, vous pouvez choisir de conserver les contextes de paramètres existants et de réutiliser les paramètres.
Si vous procédez à une installation dans un environnement d’exécution différent, ou si vous avez supprimé les contextes de paramètres précédents, entrez les paramètres de configuration dans les nouveaux contextes de paramètres, y compris les noms et les modèles de tables, comme décrit dans Paramétrez Openflow Connector for MySQL.
Accédez au contexte MySQL Ingestion Parameters et définissez les paramètres suivants :
- Définissez le paramètre Ingestion Type sur incremental. Pour obtenir plus d’informations sur les préoccupations, consultez Activer la réplication incrémentielle sans instantanés.
- Définissez le paramètre Starting Binlog Position sur Earliest. Pour obtenir plus d’informations et connaître les éventuelles préoccupations, consultez Spécifier le chargement à partir de la position du journal binaire.
Démarrez le nouveau connecteur.

Notes sur l’utilisation¶

Le nouveau connecteur utilise les tables de destination existantes qui ont été créées par le connecteur d’origine, mais le connecteur crée de nouvelles tables de journal.

Spécifier le chargement à partir de la position du journal binaire¶

Le connecteur Openflow Connector for MySQL vous permet de sélectionner la position de départ où les journaux binaires MySQL sont lus. Par défaut, le connecteur lit à partir de la position la plus récente disponible. Vous pouvez également choisir la position la plus ancienne disponible sur l’instance source. Lors de la réinstallation du connecteur, il est courant de choisir de commencer par la position la plus ancienne. Cela permet à la nouvelle instance de rattraper son retard et de continuer à répliquer les tables existantes sans avoir à créer un nouvel instantané de chacune d’entre elles.

Notez que le fait de faire passer un connecteur en cours d’exécution de la position la plus récente à la position la plus ancienne entraîne la relecture, le retraitement et la ré-application de l’intégralité du journal binaire disponible dans la table de destination.

Avertissement

Pendant la relecture du journal binaire, les colonnes et les données dans les tables de destination concernées peuvent être désynchronisées avec leurs sources, jusqu’à ce que tous les événements aient été retraités et fusionnés.

Les paramètres suivants contrôlent les chargements d’instantanés disponibles dans le contexte Ingestion Parameters :

Paramètre	Description
Position de départ du journal binaire	`Latest` (par défaut) : la lecture du flux CDC commence à la position la plus récente disponible et continue à partir de là. `Earliest` : Active le chargement incrémentiel pour démarrer ou redémarrer la lecture à partir de la position la plus ancienne disponible dans le journal binaire.
Relire les tables dans l’état	`New` (par défaut) : Lors de la relecture du journal binaire, seuls ces événements seront traités à partir des nouvelles tables ajoutées à la réplication après le début de la relecture. Les autres événements sont ignorés jusqu’à ce que le connecteur atteigne la position juste avant le début de la relecture. `Any active` : Relisez et retraitez les événements de n’importe quelle table actuellement en réplication.

Paramètre

Description

Position de départ du journal binaire

Latest (par défaut) : la lecture du flux CDC commence à la position la plus récente disponible et continue à partir de là.
Earliest : Active le chargement incrémentiel pour démarrer ou redémarrer la lecture à partir de la position la plus ancienne disponible dans le journal binaire.

Relire les tables dans l’état

New (par défaut) : Lors de la relecture du journal binaire, seuls ces événements seront traités à partir des nouvelles tables ajoutées à la réplication après le début de la relecture. Les autres événements sont ignorés jusqu’à ce que le connecteur atteigne la position juste avant le début de la relecture.
Any active : Relisez et retraitez les événements de n’importe quelle table actuellement en réplication.

Pour déterminer si le connecteur a terminé la relecture du journal binaire, procédez comme suit :

Accédez au canevas Openflow.
Ouvrez le groupe de processus Incremental Load.
Cliquez avec le bouton droit de la souris sur le processeur le plus élevé nommé Read MySQL CDC Stream, puis sélectionnez View state.
Comparez les entrées d’état :
- binlog.position.rewind : position la plus récente lue par le processeur avant le début de la relecture du journal binaire.
- binlog.position.dml : position la plus récente actuelle lue par le processeur. Tant que cette valeur est inférieure à la valeur de réinitialisation ci-dessus, le processeur continue de relire le journal binaire.

Notes sur l’utilisation¶

Une fois qu’un connecteur en cours d’exécution est activé pour lire à partir de la position la plus ancienne et démarre l’exécution, le processus ne peut pas être reconfiguré ou annulé, et il se poursuivra jusqu’à ce que la position actuellement lue atteigne la position qui précédait son démarrage.
Le passage à la position la plus ancienne sur un connecteur en cours d’exécution entraîne, pour toutes les tables en cours de retraitement, la fin des journaux existants et la création de nouvelles tables de journal.
Si le journal binaire contient des événements d’une table précédente qui a été détruite et recréée dans la base de données source, la relecture du flux traite à nouveau tous les événements dans la destination actuelle. Le connecteur ne peut pas faire la distinction entre une table source précédente et actuelle si elles partagent le même nom.