Avec les fonctions callbacks simples pour le plugin de sortie
(donc begin_cb
, change_cb
,
commit_cb
et message_cb
), les
commandes du two-phase commit comme PREPARE
TRANSACTION
, COMMIT PREPARED
et
ROLLBACK PREPARED
ne sont pas décodées. Alors que
PREPARE TRANSACTION
est ignoré, COMMIT
PREPARED
est décodé comme un COMMIT
et
ROLLBACK PREPARED
est décodé comme un
ROLLBACK
.
Pour accepter le flux des commandes de la validation en deux phases, un
plugin de sortie doit fournir des fonctions callbacks supplémentaires. Il
existe plusieurs fonctions callbacks requises pour le two-phase commit
(begin_prepare_cb
, prepare_cb
,
commit_prepared_cb
,
rollback_prepared_cb
et
stream_prepare_cb
) et une fonction callback
facultative(filter_prepare_cb
).
Si les fonctions callbacks du plugin de sortie sont fournies pour le
décodage des commandes de validation en deux phases, alors, sur un
PREPARE TRANSACTION
, les changements de cette
transaction sont décodés, passés au plugin de sortie, et la fonction
callback prepare_cb
est appelée. Ceci change de la
configuration basique de décodage où les changements sont seulement passés
au plugin de sortie quand une transaction est validée. Le début d'une
transaction préparée est indiqué par la fonction callback
begin_prepare_cb
.
Quand une transaction préparée est annulée en utilisant ROLLBACK
PREPARED
, alors la fonction callback
rollback_prepared_cb
est appelée, et quand la
transaction préparée est validée en utilisant COMMIT
PREPARED
, alors la fonction callback
commit_prepared_cb
est appelée.
En option, le plugin de sortie peut définir des règles de filtres via
filter_prepare_cb
pour décoder uniquement les
transactions en deux phases. Ceci peut se faire avec la correspondance de
motif sur gid
ou via des recherches en utilisant
xid
.
Les utilisateurs qui veulent décoder les transactions préparées doivent faire attention aux points mentionnés ci-dessous :
Si la transaction préparée a verrouillé des tables systèmes en mode exclusif, alors le décodage de la préparation peut bloquer jusqu'à la validation de la transaction principale.
La solution de réplication logique qui construit une validation en deux
phases distribuée en utilisant cette fonctionnalité peut provoquer un
deadlock si la transaction préparée a verrouillé en exclusif des tables
systèmes. Pour éviter ceci, les utilisateurs doivent éviter d'avoir des
verrous sur des tables systèmes (comme une commande
LOCK
explicite) dans de telles transactions.
Voir Section 49.8.2 pour les
détails.