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 :
-
Vérifiez que le point de reprise appartient au même flux de données, à la même trace source et au même contrat de filtrage/sortie.
-
Vérifiez que la valeur a été encodée en pourcentage sans être modifiée.
-
Vérifiez que le segment de trace contenant la position n'a pas été purgé.
-
Avec
exactlyOnceouatLeastOnce, traitez l'erreur comme un incident de récupération. Restaurez l'historique de trace, choisissez un horodatage approuvé ou une position au plus tôt, puis rapprochez l'état en aval avant de reprendre. -
Avec
atMostOnce, le service peut continuer à l'enregistrement disponible suivant. Enregistrez les données manquantes et exécutez la procédure de rapprochement approuvée par l'entreprise.
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.