Cuando un esclavo es de solo lectura , no está 100% protegido del mundo.
De acuerdo con la documentación de MySQL en read-only
Esta variable está desactivada por defecto. Cuando está habilitado, el servidor no permite actualizaciones, excepto de los usuarios que tienen el privilegio SUPER o (en un servidor esclavo) de las actualizaciones realizadas por subprocesos esclavos. En las configuraciones de replicación, puede ser útil habilitar read_only en servidores esclavos para garantizar que los esclavos acepten actualizaciones solo del servidor maestro y no de los clientes.
Por lo tanto, cualquier persona con el privilegio SUPER puede leer y escribir a voluntad a tal esclavo ...
Asegúrese de que todos los usuarios sin privilegios no tengan el privilegio SUPER.
Si desea revocar todos los privilegios SUPER de una sola vez, ejecute esto en Master y Slave:
UPDATE mysql.user SET super_priv='N' WHERE user<>'root';
FLUSH PRIVILEGES;
Con referencia al Esclavo, esto reservará el privilegio SUPER para justificar root
y evitar que los no privilegiados escriban de lo contrario estarían restringidos.
ACTUALIZACIÓN 2015-08-28 17:39 EDT
Acabo de enterarme recientemente que MySQL 5.7 presentará super_read_only .
Esto detendrá a los usuarios SUPER en sus pistas porque los 5.7 Docs dicen
Si la variable del sistema read_only está habilitada, el servidor permite actualizaciones de clientes solo de usuarios que tienen el privilegio SUPER. Si la variable del sistema super_read_only también está habilitada, el servidor prohíbe las actualizaciones de clientes incluso de usuarios que tienen SUPER. Consulte la descripción de la variable de sistema read_only para obtener una descripción del modo de solo lectura e información sobre cómo interactúan read_only y super_read_only.
Los cambios en super_read_only en un servidor maestro no se replican en servidores esclavos. El valor se puede establecer en un servidor esclavo independiente de la configuración en el maestro.
super_read_only fue agregado en MySQL 5.7.8.