¿Previene las escrituras sin replicación en MySQL slave?

Tenemos algunos servidores de bases de datos MySQL configurados con replicación basada en filas, para el rendimiento. El software escribe en el maestro y lee desde el maestro o el esclavo. Todo funciona muy bien, en su mayor parte.

Tengo entendido que MySQL permitirá las escrituras al esclavo, aunque sabe que es un esclavo MySQL. Idealmente, me gustaría cerrar esto, por lo que incluso si alguien escribe un código incorrecto que obtiene una conexión de lectura y lo hace UPDATE, arrojará un error en lugar de poner datos en el esclavo.

¿Hay alguna manera de hacer esto en MySQL? Obviamente, también nos gustaría hacer esto imposible desde nuestro software, pero como un firewall en nuestros servidores, me gustaría estar lo más a la defensiva posible.

¡Gracias!

Habilite la read-onlyopción en my.cnf. También se puede especificar como una bandera en la línea de comando usando --read-onlymysqld.

Como alternativa a la configuración read_only=1(por ejemplo, cuando hay otras bases de datos de scratchpad / informes / desarrollo en la instancia esclava), a veces elimino todos los privilegios que no sean SELECT de todos los usuarios a la base de datos que estoy replicando.

Es decir, después de ejecutar GRANT comando en el maestro, ejecuto el comando REVOKE en el esclavo.

A partir de MySQL 5.7.8 , ahora hay una super_read_onlyopción que evita que incluso los usuarios SUPER realicen actualizaciones de clientes. No interrumpe el proceso de replicación. Al igual que con otras configuraciones, se puede configurar:

• en formato de línea de comando ( --super_read_only=ON),
• como una variable en my.cnf (super_read_only=1 ), o
• desde el indicador del cliente (SET GLOBAL super_read_only = 1; ).

Tenga en cuenta que:

• Habilitando super_read_only implícitamente habilitaread_only
• Deshabilitar read_onlydeshabilita implícitamentesuper_read_only

Algunas advertencias:

• Ninguno read_only tampoco super_read_onlyimpedirá operaciones en tablas temporales.
• No evitarán operaciones de metadatos como ANALYZE TABLE y OPTIMIZE TABLE.
• super_read_onlySe han reportado errores para ciertas consultas con habilitado.

Referencia: https://www.percona.com/blog/2016/09/27/using-the-super_read_only-system-variable/

Como sugiere la primera publicación, lo haces con permisos. La opción de solo lectura no funciona para superusuarios como FYI y tampoco es realmente una solución viable para un esclavo donde desea evitar escrituras. Debe evitar las escrituras con permisos de usuario / base de datos / tabla. Por un lado, el usuario de replicación aún debe poder escribir en el esclavo para mantenerlo sincronizado con el maestro. La mejor manera de controlar las escrituras es que necesita revocar las opciones que permiten escrituras (es decir, inserciones, creaciones, etc.) para el usuario en cuestión que deberían estar haciendo lecturas solo en el esclavo.

Solo otorgue derechos relacionados con la replicación a los usuarios del esclavo. Aún tiene el problema de los derechos de usuario root, pero puede eliminar el acceso root remoto al servidor de base de datos.