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 47.8.2 pour les
      détails.