Auteur : shuixian
Les procédures stockées et les fonctions MySQL 5.1 fonctionnent-elles sur la réplication ?
Oui, le comportement standard est effectué dans les procédures stockées et les fonctions qui sont répliquées du serveur MySQL maître vers le serveur esclave.
Les procédures stockées et les fonctions créées sur le serveur maître peuvent-elles être copiées sur le serveur esclave ?
Oui, les procédures stockées et les fonctions exécutées via des instructions DDL générales, dont la création sur le serveur maître sont copiées sur le serveur esclave, la cible existera donc sur les deux serveurs. Les instructions ALTER et DROP pour les procédures et fonctions stockées sont également répliquées.
Comment le comportement se produit-il dans les procédures et fonctions stockées répliquées ?
MySQL enregistre chaque événement DML qui se produit dans les procédures et fonctions stockées et réplique ces actions individuelles sur des serveurs esclaves. Les appels réels aux procédures et fonctions stockées ne sont pas copiés.
Existe-t-il des exigences de sécurité particulières pour l’utilisation conjointe de procédures stockées, de fonctions et de réplication ?
Oui, étant donné qu'un esclave est autorisé à exécuter toute instruction qui lit le journal binaire du maître, les contraintes de sécurité spécifiées existent pour les procédures stockées et les fonctions utilisées avec la réplication. Si la réplication ou la journalisation binaire sont activées en général (à des fins de récupération ponctuelle), alors l'administrateur de base de données MySQL dispose de deux options de sécurité :
Tout utilisateur souhaitant créer des procédures stockées doit disposer des privilèges SUPER.
Alternativement, un administrateur de base de données peut définir la variable système log_bin_trust_routine_creators sur 1, ce qui permettra à toute personne disposant des autorisations standard CREATE ROUTINE de créer des procédures et des fonctions stockées.
Quelles sont les restrictions sur le comportement de copie de procédures et de fonctions stockées ?
Les lignes indéterminées (aléatoires) ou temporelles intégrées dans les procédures stockées ne sont pas copiées correctement. Les résultats générés aléatoirement, de par leur nature même, sont prévisibles et ne peuvent pas être clonés de manière fiable. Par conséquent, un comportement aléatoire répliqué sur l’esclave ne reflétera pas celui qui se produit sur le maître. Notez que déclarer une procédure stockée ou une fonction DETERMINISTIC ou définir la variable système sur 0 dans log_bin_trust_routine_creators permettra d'appeler des opérations sur des valeurs aléatoires.
De plus, le comportement temporel n'est pas reproductible sur le serveur esclave, car ce comportement temporel n'est pas reproductible dans la procédure stockée via le journal binaire utilisé pour la réplication, car le journal binaire enregistre uniquement les événements DML et n'inclut pas de contrainte de synchronisation.
Enfin, si une erreur se produit dans une table non interactive lors d'une action DML volumineuse (telle qu'une insertion groupée), la table non interactive peut subir une réplication et le serveur maître peut être partiellement mis à jour à partir de l'action DML dans la version répliquée. du tableau non interactif. Mais en raison de l’erreur survenue, aucune mise à jour n’a été effectuée sur le serveur esclave. Pour le comportement DML de la fonction, l'espace de travail sera exécuté avec le mot-clé IGNORE afin que les mises à jour qui provoquent des erreurs sur le serveur maître soient ignorées et que les mises à jour qui ne provoquent pas d'erreurs soient copiées sur le serveur esclave.