Realtime Compute for Apache Flink:FAQ et solutions pour l'ingestion

Symptôme

• Le job redémarre en boucle pendant la phase de snapshot.

• Les journaux du JobManager contiennent une trace de pile OutOfMemoryError (OOM).

• Dans l'onglet Alarm, les métriques Num of remaining SnapshotSplits et Num of processed SnapshotSplits affichent des valeurs exceptionnellement élevées.

Cause

Pendant la phase de snapshot, la source MySQL persiste toutes les métadonnées des shards de table dans l'état du job Flink. Si le job traite un volume de données important ou utilise des tailles de shard très petites, le JobManager crée un nombre excessif de shards, ce qui épuise la mémoire disponible.

Solution

1. Augmentez les ressources mémoire allouées au JobManager.

2. Ajustez les paramètres suivants pour augmenter la mémoire heap et off-heap du JobManager :

   • jobmanager.memory.heap.size

   • jobmanager.memory.off-heap.size

Symptôme

• Le TaskManager manque de mémoire tard dans la phase de snapshot, généralement lorsqu'il ne reste qu'un petit nombre de shards.

• La recherche de using select statement dans les journaux du TaskManager révèle que la dernière requête illimitée implique un volume de données très important.

Cause

Une lecture prolongée des données pendant la phase de snapshot entraîne l'accumulation de données incrémentielles dans les derniers shards. Lorsque le TaskManager traite ces grands shards accumulés, il manque de mémoire.

Solution

1. Définissez l'option suivante :

      scan.incremental.snapshot.unbounded-chunk-first.enabled: true

2. Réexécutez le snapshot.

Symptôme

• Le job entre en phase incrémentielle mais échoue lors de la restauration de l'état.

• Les journaux du JobManager indiquent une erreur OOM.

Cause

Les versions VVR 11.1 et antérieures peuvent ne pas nettoyer correctement les informations de schéma de table persistantes de l'état du job après la transition vers la phase incrémentielle. Ces données de schéma résiduelles s'accumulent et provoquent une erreur OOM lorsque le job restaure à partir d'un point de contrôle.

Solution

1. Mettez à niveau vers VVR 11.2 ou une version ultérieure.

Symptôme

• Le job continue de s'exécuter sans redémarrer après une modification de schéma de table sans verrouillage.

• La métrique CurrentFetchTimeLag progresse comme prévu, indiquant que les données sont récupérées.

• La source MySQL cesse de produire de nouvelles données et la métrique CurrentEmitTimeLag cesse de se mettre à jour.

Cause

Les versions VVR 11.1 et antérieures ne peuvent pas gérer correctement les événements DDL générés par les outils de modification de schéma sans verrouillage tels que pt-osc, ce qui bloque le pipeline de données.

Solution

1. Mettez à niveau vers VVR 11.2 ou une version ultérieure.

2. Définissez l'option suivante :

      scan.parse.online.schema.changes.enabled: true

Symptôme

• Le job redémarre de manière inattendue suite à une modification de schéma de table sans verrouillage (par exemple, en utilisant pt-osc).

• Les journaux de l'opérateur Transform indiquent une erreur d'incompatibilité de type de colonne.

Cause

Dans VVR 11.1, si un volume important de données est inséré dans une table pendant une modification de schéma sans verrouillage, le moteur peut générer un événement non analysable.

Solution

1. Mettez à niveau vers VVR 11.2 ou une version ultérieure.

2. Effectuez un redémarrage avec état à partir d'un point de sauvegarde créé avant la modification de schéma sans verrouillage.

Symptôme

• Un redémarrage avec état à partir d'un point de sauvegarde créé avant une modification de schéma de table échoue.

• Le message d'erreur indique une exception d'incompatibilité de schéma de table lors de la consommation des journaux binaires.

Cause

Les versions VVR 11.1 et antérieures ne prennent pas en charge les redémarrages avec état à partir de points de sauvegarde contenant un schéma de table incompatible.

Solution

1. Mettez à niveau vers VVR 11.2 ou une version ultérieure.

2. Après la mise à niveau, redémarrez le job à partir d'un point de sauvegarde antérieur à la modification de schéma.

Symptôme

• Le job Flink CDC échoue pendant la phase de snapshot avec une erreur indiquant que la position requise du journal binaire n'existe plus ou a été purgée.

Cause

Un job Flink CDC fonctionne en deux phases séquentielles avec des modèles de consommation de journaux binaires différents :

• Phase de snapshot : Lit les données historiques et rejoue les entrées de journal binaire relativement anciennes. Si la phase de snapshot prend beaucoup de temps, MySQL peut purger les fichiers de journal binaire dont le job a encore besoin avant la fin du snapshot. Cela provoque l'échec du job car la position de journal requise n'est plus disponible.

• Phase incrémentielle : Lit les entrées de journal binaire les plus récentes en quasi temps réel. Comme la phase incrémentielle suit toujours la dernière position du journal, elle n'est généralement pas affectée par les politiques standard de purge des journaux binaires.

Solution

1. Vérifiez si votre job se trouve actuellement en phase de snapshot ou en phase incrémentielle en examinant les métriques de surveillance du job (par exemple, la métrique Num of remaining SnapshotSplits : une valeur supérieure à zéro indique que le job est toujours en phase de snapshot).

2. Si le job échoue en phase de snapshot en raison de la purge des journaux binaires, effectuez l'une ou les deux actions suivantes :

   • Prolongez la période de rétention des journaux binaires sur votre instance MySQL pour couvrir la durée prévue du snapshot :

     • MySQL 5.7 et versions antérieures : définissez expire_logs_days sur un nombre de jours suffisant.

     • MySQL 8.0 et versions ultérieures : définissez binlog_expire_logs_seconds sur un nombre de secondes suffisant.

   • Réduisez la durée du snapshot en effectuant un redémarrage sans état et en augmentant le parallélisme du job. Un degré de parallélisme plus élevé accélère la phase de snapshot, réduisant ainsi la fenêtre durant laquelle les journaux binaires peuvent être purgés.