Point de reprise, récupération et sémantique de livraison

Découvrez le point de reprise, la récupération et la distribution à partir de la configuration des flux de données.

Le contrat public pos

Chaque enregistrement LMD ou LDD non-métadonnées inclut un jeton pos opaque par défaut. En interne, le jeton contient suffisamment d'informations de positionnement GoldenGate pour identifier un enregistrement, notamment des informations de validation ou de séquence, une identité de transaction et un séquencement d'enregistrements. Son encodage n'est pas un format public coordonné par la source et peut varier selon le type et la version de la source.

Faire Ne pas
Stockez la chaîne exacte après un traitement réussi. Analysez-le pour obtenir un numéro SCN Oracle, un numéro LSN PostgreSQL, une coordonnée de journal binaire MySQL, un numéro LSN SQL Server ou tout autre décalage spécifique à la source.
Portée sur le flux de données, le contrat de trace source et le consommateur. Comparez les positions lexiquement ou numériquement pour déterminer l'ordre.
Codez-le en pourcentage lorsqu'il est utilisé en tant que begin dans une URL. Tronquer, normaliser, concaténer, décrypter ou réécrire.
Utilisez des champs csn, xid, opSeqno et transInd distincts pour les diagnostics ou l'analyse des transactions. Réutiliser une position à partir d'un autre flux, d'un contrat de filtre différent ou d'un autre environnement.

Portabilité de la source : l'algorithme de récupération client est intentionnellement le même pour Oracle, PostgreSQL, MySQL, SQL Server et d'autres sources prises en charge : persistez le fichier pos opaque et restez-le inchangé. L'analyse des coordonnées propres à la source n'est ni requise ni prise en charge par le contrat client Data Streams.

Un point de reprise doit représenter le dernier enregistrement dont l'effet commercial est durable. L'enregistrement avant l'écriture de l'entreprise peut entraîner la perte de données après une panne. L'enregistrement après une écriture non idempotente dans une transaction distincte peut produire un doublon après une panne.

Modèles exactement une fois de bout en bout

Modèle Fonctionnement Utiliser quand
Transaction de puits atomique et de point de reprise Ecrivez l'enregistrement métier et le nouveau fichier pos dans la même transaction de base de données. Le récepteur et le point de reprise peuvent partager une banque de données transactionnelle.
Clé d'idempotence Utilisez pos, ou une clé métier plus une identité d'opération, en tant que clé unique. Une nouvelle tentative du même enregistrement devient une opération "no-op". Le récepteur prend en charge l'unicité ou les écritures conditionnelles.
Journal de transfert durable Ajoutez l'enregistrement et pos de manière atomique à un journal durable, puis traitez-le indépendamment. Le traitement métier est lent, en plusieurs étapes ou s'étend sur des systèmes.
Au moins une fois avec réconciliation Accepter les doublons, les supprimer périodiquement et rapprocher les nombres ou les checksums. Le cas d'emploi tolère une éventuelle correction.

REMARQUE : Le flux de données exactlyOnce décrit la réponse de suppression et de récupération des doublons côté service. Il n'a pas d'effet secondaire en aval arbitraire exactement une fois, car le protocole WebSocket n'a pas d'accusé de réception transactionnel par enregistrement avec le client.

Qualité de service

Reportez-vous aux instructions relatives à la qualité de service du tableau suivant :

Mode Dupliquer Poste enregistré non disponible Utilisation recommandée
exactlyOnce Supprime les doublons reconnus lors de la récupération et de la gestion du redémarrage/de l'abandon de la trace source. Echec de la connexion avec une erreur. Valeur par défaut pour le traitement fonctionnel durable. Associez-vous à une logique de consommation atomique ou idempotente.
atLeastOnce Ne supprime pas les doublons lors de la récupération et du redémarrage/du traitement d'abandon de la trace source. Echec de la connexion avec une erreur. A utiliser lorsque la réexécution est préférée et que le consommateur est conçu pour supprimer les doublons.
atMostOnce Supprime les doublons reconnus. Le service recherche le prochain enregistrement disponible et continue, ce qui peut ignorer les données. Utilisez uniquement lorsque la perte de données est explicitement acceptable et que la progression est plus importante que l'exhaustivité.

Métadonnées de transaction et ordre

Reportez-vous au tableau suivant pour connaître les métadonnées de transaction et les exigences en matière de tri :

Champ Objectif Limites
xid Regroupe les enregistrements associés à une transaction source. Le format dépend de la source et doit être traité comme une chaîne.
csn Affiche le numéro de séquence de validation source lorsqu'il est configuré. La signification et le format dépendent de la source. N'utilisez pas le jeton de redémarrage.
opSeqno Numéro de séquence d'enregistrement au sein de la transaction. Activez-le et renommez-le de façon explicite.
transInd B en premier, M au milieu, E en dernier ou W transaction entière/à opération unique. Le filtrage peut supprimer des enregistrements et rendre la séquence observée incomplète. Le traitement coordonné peut également réduire l'utilité.
pos Position de récupération unique pour l'enregistrement. Opaque ; ne pas trier ou dériver les limites de transaction à partir de son texte.

Ne présumez pas qu'une connexion commence toujours à une limite de transaction. Une recherche d'horodatage ou une limite de trace conservée peut commencer une fois que les opérations précédentes ne sont plus disponibles. Si l'application nécessite des transactions source complètes, concevez un tampon de transaction, définissez des limites pour les transactions volumineuses et indiquez les actions à effectuer lorsque le début d'une transaction n'est pas disponible.

Lorsqu'un poste enregistré n'est pas disponible

Pour vérifier un poste enregistré qui devient indisponible, vérifiez les points suivants :

Planification de la conservation des traces

Définissez la conservation de la trace pour dépasser l'objectif de point de récupération plus la détection opérationnelle et le temps de réponse. Par exemple, un consommateur qui peut être hors ligne pendant 24 heures et qui a besoin de 12 heures pour la réponse aux incidents a besoin de plus de 36 heures de trace disponible, avec une marge supplémentaire pour les retards et la maintenance importants. bufferSize n'étend pas la conservation de trace.