Quelle est la manière la plus sûre de changer le format binlog lors de l'exécution?

En raison de l'avertissement suivant dans mysqld.log:

[Avertissement] Instruction non sécurisée écrite dans le journal binaire en utilisant le format d'instruction depuis BINLOG_FORMAT = STATEMENT. L'instruction n'est pas sûre car elle utilise une clause LIMIT. Cela n'est pas sûr car l'ensemble des lignes incluses ne peut pas être prévu.

Je souhaite basculer le format de réplication sur MIXED.

Mais selon le document MySQL:

La commutation du format de réplication au moment de l'exécution n'est pas recommandée lorsqu'il existe des tables temporaires, car les tables temporaires ne sont enregistrées que lors de l'utilisation de la réplication basée sur des instructions, alors qu'avec la réplication basée sur des lignes, elles ne sont pas enregistrées.

Ainsi, la question est de savoir comment puis-je identifier s'il existe des tables temporaires pour changer le format du journal binaire en toute sécurité?

mysql replication

— quanta
source

Avertissement rapide. Méfiez-vous de cela lorsque vous passez de RBR-> SBR et utilisez read-commit: bugs.mysql.com/bug.php?id=62493

— Morgan Tocker

Puisqu'un binlog aura un format spécifique au moment où vous le ferez, vous pouvez décider de ne pas jouer avec les deux formats ensemble bien que MySQL (eh Oracle [ne peut toujours pas rouler sur ma langue]) a construit cette fonctionnalité.

Pour jouer en toute sécurité sans redémarrage de mysql, essayez ce qui suit:

FLUSH TABLES WITH READ LOCK;
FLUSH LOGS;
SET GLOBAL binlog_format = 'MIXED';
FLUSH LOGS;
UNLOCK TABLES;

Cela laissera le dernier binlog au format «MIXTE». L'avant-dernier (avant-dernier) binlog existe simplement pour fermer le dernier binlog qui était dans le format précédent.

Toutes les sessions existantes avant la première FLUSH LOGS;commenceront à écrire dans le dernier binlog une fois UNLOCK TABLES;exécuté.

Essaie !!!

CAVEAT

Donner du crédit là où le crédit est dû, ma réponse est vraiment superposée à la réponse de @ Jonathan . Je ferme et j'ouvre les binlogs en plus. Il obtient un +1 pour avoir mis cela en évidence en premier.

MISE À JOUR 2011-10-12 13:58 EDT

Si vous faites cela à un maître actif et qu'il y a un ou plusieurs esclaves qui se répliquent à partir de ce maître, vous devez également vous soucier du fait que les journaux de relais sont au nouveau format. Voici ce que vous pouvez faire:

Sur l'esclave, exécutez STOP SLAVE;

Sur le Master, exécutez ceux-ci:

FLUSH TABLES WITH READ LOCK;
FLUSH LOGS;
SET GLOBAL binlog_format = 'MIXED';
FLUSH LOGS;
UNLOCK TABLES;

Sur l'esclave, exécutez START SLAVE;

L'exécution STOP SLAVE;et la START SLAVE;rotation des journaux de relais entraînent la réplication des nouvelles entrées, quel que soit le format. Vous pouvez également appliquer la modification binlog_format à l'esclave.

— RolandoMySQLDBA
source

Une chose à garder à l'esprit est que les paramètres de réplication mysql sont réellement définis sur une base par session client. La définition du binlog_format global modifie simplement la valeur des NOUVELLES sessions. Ainsi, si vous l'exécutez sur un système avec des clients connectés en permanence, toutes les modifications que vous apportez aux paramètres ne seront pas immédiatement applicables même si vous effectuez le vidage et le verrouillage comme spécifié ici - elles ne prendront effet que lorsque les clients reconnectez-vous (ou définissez la valeur dans leur propre session, mais d'après mon expérience, la première est plus probable).

— Austin Mills

Pour les curieux, vous pouvez également mettre ce "binlog_format = 'MIXED';" dans votre my.cnf.

— Christian

Pour info, cette réponse n'est pas en accord avec une réponse ici: dba.stackexchange.com/questions/58539/…

— HTTP500

Le manuel indique : Cela signifie que la modification du format de journalisation sur un maître de réplication ne fait pas en sorte qu'un esclave modifie son format de journalisation pour correspondre. (..snip ..) La modification du format de journalisation binaire sur le maître pendant la réplication est en cours, ou sans le changer également sur l'esclave, ce qui peut entraîner des résultats inattendus, voire entraîner l'échec total de la réplication.

— Halfgaar

@Halfgaar La semaine dernière, j'ai changé trois fois un esclave de MIXED en STATEMENT sans aucun effet néfaste. Je faisais cela parce que la réplication était interrompue en raison d'une condition de concurrence. La table est devenue inexistante sur un esclave avant l'exécution de la requête. Donc, je suis passé à STATEMENT pour stable comme cette situation. Bien sûr, toutes les écritures ont été arrêtées pendant que je faisais cela. BTW J'ai aussi fait le Master.

— RolandoMySQLDBA

Pour basculer binlog_format au moment de l'exécution, vous pouvez faire:

set global binlog_format = 'MIXED';

Cela définira toutes les NOUVELLES sessions au format binlog mixte. Toutes les sessions existantes seront ce qui a été défini précédemment jusqu'à leur fin.

Vous pouvez également le faire set session binlog_format = 'MIXED';manuellement pour résoudre tout problème spécifique à la session.

— Jonathan
source

Je ne demande pas le chemin, je demande le moyen le plus sûr et comment puis-je vérifier s'il existe des tables temporaires.

— quanta

Définir la variable globale en premier et attendre la fin des sessions restantes est le moyen le plus sûr.

— Jonathan