Lorsqu'un esclave est en lecture seule , il n'est pas à 100% protégé du monde.
Selon la documentation MySQL sur read-only
Cette variable est désactivée par défaut. Lorsqu'il est activé, le serveur n'autorise aucune mise à jour sauf des utilisateurs qui ont le privilège SUPER ou (sur un serveur esclave) des mises à jour effectuées par des threads esclaves. Dans les configurations de réplication, il peut être utile d'activer read_only sur les serveurs esclaves pour garantir que les esclaves n'acceptent les mises à jour que du serveur maître et non des clients.
Ainsi, toute personne disposant du privilège SUPER peut lire et écrire à volonté sur un tel esclave ...
Assurez-vous que tous les utilisateurs non privilégiés n'ont pas le privilège SUPER.
Si vous souhaitez révoquer tous les privilèges SUPER en une seule fois, veuillez exécuter ceci sur Master et Slave:
UPDATE mysql.user SET super_priv='N' WHERE user<>'root';
FLUSH PRIVILEGES;
En ce qui concerne l'esclave, cela réservera le privilège SUPER à juste root
et empêchera les non-privilégiés de faire des écritures dont ils seraient autrement limités.
MISE À JOUR 2015-08-28 17:39 EDT
Je viens d'apprendre récemment que MySQL 5.7 introduira super_read_only .
Cela arrêtera les utilisateurs SUPER sur leurs traces, car les documents 5.7 disent
Si la variable système read_only est activée, le serveur n'autorise les mises à jour client que des utilisateurs disposant du privilège SUPER. Si la variable système super_read_only est également activée, le serveur interdit les mises à jour des clients même des utilisateurs disposant de SUPER. Voir la description de la variable système read_only pour une description du mode en lecture seule et des informations sur l'interaction entre read_only et super_read_only.
Les modifications apportées à super_read_only sur un serveur maître ne sont pas répliquées sur les serveurs esclaves. La valeur peut être réglée sur un serveur esclave indépendamment du réglage sur le maître.
super_read_only a été ajouté dans MySQL 5.7.8.