Eu tenho a replicação em execução no Percona Server 5.5 seguindo este guia e me perguntei se eu deveria adicionar read-only=1ao meu escravo my.cnfpara torná-lo somente leitura?

O guia configura a replicação para a tabela mysql para que os usuários sejam replicados, mas eu estou usando principalmente o slave para usar o mysqldumps, e em uma emergência reconfigurando-o para ser mestre, então não acredito que precisamos (ou devíamos) habilitar a gravação ativada no constantemente?

Quando um escravo é somente leitura , ele não é 100% protegido contra o mundo.

De acordo com a documentação do MySQL em read-only

Esta variável está desativada por padrão. Quando está ativado, o servidor não permite atualizações, exceto usuários que possuem o privilégio SUPER ou (em um servidor escravo) de atualizações executadas por encadeamentos escravos. Nas configurações de replicação, pode ser útil ativar o read_only em servidores escravos para garantir que os escravos aceitem atualizações apenas do servidor mestre e não dos clientes.

Assim, qualquer pessoa com privilégio SUPER pode ler e escrever à vontade para um Escravo ...

Verifique se todos os usuários não privilegiados não possuem o privilégio SUPER.

Se você deseja revogar todos os privilégios SUPER de uma só vez, execute isso no Master e Slave:

UPDATE mysql.user SET super_priv='N' WHERE user<>'root';
FLUSH PRIVILEGES;

Com referência ao Escravo, isso reservará o privilégio SUPER para rootjustificar e impedir que os não privilegiados façam gravações das quais seriam restringidos.

UPDATE 2015-08-28 17:39 EDT

Acabei de aprender recentemente que o MySQL 5.7 apresentará super_read_only .

Isso interromperá os usuários SUPER, porque os 5,7 documentos dizem

Se a variável de sistema read_only estiver ativada, o servidor permitirá atualizações do cliente apenas de usuários que tenham o privilégio SUPER. Se a variável de sistema super_read_only também estiver ativada, o servidor proibirá as atualizações do cliente, mesmo dos usuários que possuem SUPER. Consulte a descrição da variável de sistema read_only para obter uma descrição do modo somente leitura e informações sobre como o read_only e o super_read_only interagem.

As alterações em super_read_only em um servidor mestre não são replicadas para servidores escravos. O valor pode ser definido em um servidor escravo independente da configuração no mestre.

super_read_only foi adicionado no MySQL 5.7.8.

Um escravo de replicação do MySQL deve ser definido como somente leitura?

Sim, é melhor executar servidores escravos com os modos de R / O disponíveis. Usuários anteriormente privilegiados podiam modificar os dados de um escravo de qualquer maneira, mas posteriormente eles também obtiveram seu "botão" de restrição de R / O.

Por que é importante - é melhor falhar com a gravação do que se arrepender com uma gravação incorreta que poderia efetivamente tornar o escravo inutilizável devido a simples confusão de dados ou coisas como conflito de chaves que interromperiam a replicação (não é mais um escravo real de novo).

Também há software usado para orquestração / divisão de carga que levaria em consideração o status de E / S dos servidores nos pools configurados para o roteamento de solicitações adequado entre esses servidores.

Isso é segurança. Use-o.

O problema aqui, incluído o MySQL 8.0, é que o MySQL não o força a definir read_only = ONquando você executa o start slavecomando. Porque é um problema? Como quase todos os DBAs do MySQL usam seus escravos no RO, para impedir a corrupção de dados, e sempre existe um dba que acidentalmente executa erroneamente um SQL que modifica os dados em um escravo ou um aplicativo que não muda seu conf. Se eu quiser escrever em escravos, porque ele tem vários esquemas e preciso escrever nesse esquema, então o read_onlycomando deve ser mais inteligente e vamos fazer a read_only for schema. Isso pode ser muito útil em servidores multi-master e escravos que fazem a Replicate_Ignore_DB. Portanto, por enquanto, você deve fazer o controle manualmente e ter muito cuidado.

Apreciar.