Предотвратить запись без репликации в подчиненный MySQL?

У нас есть несколько серверов баз данных MySQL с репликацией на основе строк для повышения производительности. Программное обеспечение записывает данные в ведущее устройство и читает либо из ведущего устройства, либо из ведомого устройства. Все работает отлично, по большей части.

Насколько я понимаю, MySQL будет разрешать запись на подчиненное устройство, даже если оно знает, что это подчиненное MySQL. В идеале мне бы хотелось закрыть это, поэтому, даже если кто-то напишет какой-нибудь плохой код, который получит соединение для чтения и сделает UPDATE, он выдаст ошибку, а не поместит данные на ведомое устройство.

Есть ли способ сделать это в MySQL? Очевидно, что мы хотели бы сделать это невозможным и с помощью нашего программного обеспечения, но, как брандмауэр на наших серверах, я бы хотел быть максимально защищенным.

Благодарность!

Включите эту read-onlyопцию в my.cnf. Он также может быть указан как флаг в командной строке с --read-onlyпомощью mysqld.

В качестве альтернативы настройке read_only=1(например, когда на ведомом экземпляре есть другие базы данных блокнота / отчетов / разработки), я иногда отбрасываю все привилегии, кроме SELECT, для всех пользователей в базу данных, которую я реплицирую.

То есть после запуска команды GRANT на главном компьютере я запускаю команду REVOKE на ведомом устройстве.

Начиная с MySQL 5.7.8 , теперь есть super_read_onlyопция, которая не позволяет даже пользователям SUPER выполнять обновления клиента. Это не нарушает процесс репликации. Как и с другими настройками, его можно установить:

• в формате командной строки ( --super_read_only=ON),
• в качестве переменной в my.cnf ( super_read_only=1) или
• из командной строки клиента ( SET GLOBAL super_read_only = 1;).

Обратите внимание, что:

• Включение super_read_onlyнеявно включаетread_only
• Отключение read_onlyнеявно отключаетsuper_read_only

Некоторые предостережения:

• Ни то, read_onlyни другое не super_read_onlyпомешает работе с временными таблицами.
• Они не будут препятствовать операциям метаданных, таким как ANALYZE TABLE и OPTIMIZE TABLE.
• super_read_onlyСообщается об ошибках для определенных запросов с включенным.

Ссылка: https://www.percona.com/blog/2016/09/27/using-the-super_read_only-system-variable/

Как следует из первого поста, вы делаете это с разрешениями. Опция «только для чтения» не работает для суперпользователей в качестве FYI, а также не является реально работоспособным решением для ведомого, где вы хотите предотвратить записи. Вы должны предотвратить записи с правами пользователя / базы данных / таблицы. Во-первых, пользователь репликации по-прежнему должен иметь возможность записи на ведомое устройство, чтобы синхронизировать его с ведущим. Лучший способ управления записями - отменить опции, которые разрешают запись (т.е. вставку, создание и т. Д.) Для данного пользователя, который должен выполнять чтение только на ведомом устройстве.

Предоставляйте права на репликацию только пользователям на ведомом устройстве. У вас все еще есть проблема прав пользователя root, но вы можете удалить удаленный доступ root к серверу БД.