Empêcher les écritures de non-réplication sur l'esclave MySQL?

Nous avons certains serveurs de base de données MySQL configurés avec une réplication basée sur les lignes, pour des performances. Le logiciel écrit sur le maître et lit à partir du maître ou de l'esclave. Tout fonctionne très bien, pour la plupart.

Je crois comprendre que MySQL autorisera les écritures sur l'esclave, même s'il sait que c'est un esclave MySQL. Idéalement, je voudrais un peu fermer cela, donc même si quelqu'un écrit un mauvais code qui obtient une connexion en lecture et fait un UPDATE, il générera une erreur plutôt que de mettre des données sur l'esclave.

Existe-t-il un moyen de le faire dans MySQL? Évidemment, nous aimerions rendre cela impossible à partir de notre logiciel, mais comme un pare-feu sur nos serveurs, je voudrais être aussi défensif que possible.

Merci!

Activez l' read-onlyoption dans my.cnf. Il peut également être spécifié comme indicateur sur la ligne de commande à l'aide --read-onlyde mysqld.

Comme alternative à la configuration read_only=1(par exemple, lorsqu'il existe d'autres bases de données de bloc-notes / rapports / développement sur l'instance esclave), je dépouille parfois tous les privilèges autres que SELECT de tous les utilisateurs sur la base de données que je réplique.

Autrement dit, après avoir exécuté la commande GRANT sur le maître, j'exécute la commande REVOKE sur l'esclave.

Depuis MySQL 5.7.8 , il existe désormais une super_read_onlyoption qui empêche même les utilisateurs SUPER d'effectuer des mises à jour client. Il ne perturbe pas le processus de réplication. Comme avec d'autres paramètres, il peut être défini:

• au format ligne de commande ( --super_read_only=ON),
• en tant que variable dans my.cnf ( super_read_only=1), ou
• à partir de l'invite client ( SET GLOBAL super_read_only = 1;).

Notez que:

• L'activation super_read_onlyactive implicitementread_only
• La désactivation read_onlydésactive implicitementsuper_read_only

Quelques mises en garde:

• Ni , read_onlyni super_read_onlyempêchera sur des fichiers temporaires.
• Ils n'empêcheront pas les opérations de métadonnées comme ANALYZE TABLE et OPTIMIZE TABLE.
• Des bogues pour certaines requêtes avec super_read_onlyactivé ont été signalés.

Référence: https://www.percona.com/blog/2016/09/27/using-the-super_read_only-system-variable/

Comme le premier article le suggère, vous le faites avec des autorisations. L'option en lecture seule ne fonctionne pas pour les super utilisateurs en tant que FYI et ce n'est pas vraiment une solution réalisable pour un esclave où vous souhaitez empêcher les écritures. Vous devez empêcher les écritures avec les autorisations utilisateur / base de données / table. D'une part, l'utilisateur de réplication doit toujours être capable d'écrire sur l'esclave pour le synchroniser avec le maître. Une meilleure façon de contrôler les écritures est que vous devez révoquer les options qui autorisent les écritures (c.-à-d. Insère, crée, etc.) pour l'utilisateur en question qui devrait faire des lectures uniquement sur l'esclave.

Accordez uniquement des droits de réplication aux utilisateurs sur l'esclave. Vous avez toujours le problème des droits d'utilisateur root, mais vous pouvez supprimer l'accès root distant au serveur de base de données.