У мене запущена реплікація на Percona Server 5.5, дотримуючись цього посібника, і запитав, чи слід додати read-only=1до свого раба, my.cnfщоб зробити його тільки для читання?

Посібник встановлює реплікацію для таблиці mysql, тому користувачі реплікуються, але я в першу чергу використовую підлеглий, щоб взяти mysqldumps, а в екстреному випадку перенастроюючи його на головний, тому я не вірю, що нам потрібно (або повинно бути) включити запис на це постійно?

Коли Раб є лише для читання , він не на 100% захищений від світу.

Відповідно до документації MySQL на read-only

Ця змінна вимкнено за замовчуванням. Коли це ввімкнено, сервер не допускає оновлень, за винятком користувачів, які мають привілей SUPER або (на підлеглому сервері) оновлень, виконаних потоками підлеглого. У налаштуваннях реплікації може бути корисним включити read_only на підлеглому сервері, щоб переконатися, що раби приймають оновлення лише з головного сервера, а не від клієнтів.

Таким чином, кожен, хто має привілей СУПЕР, може читати та писати за бажанням такому Рабу ...

Переконайтесь, що всі непривілейовані користувачі не мають привілею SUPER.

Якщо ви хочете відкликати всі привілеї SUPER за один кадр, запустіть це на Master і Slave:

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

Що стосується Раба, rootто це залишатиме за собою привілей СУПЕР справедливого та запобігає непривілейованому виконанню записів, від яких інакше вони будуть обмежені.

ОНОВЛЕННЯ 2015-08-28 17:39 EDT

Нещодавно я дізнався, що MySQL 5.7 представить super_read_only .

Це зупинить користувачів SUPER у їхніх треках, оскільки кажуть 5.7 Документів

Якщо системна змінна read_only включена, сервер дозволяє оновлення клієнта лише від користувачів, які мають привілей SUPER. Якщо також включена системна змінна super_read_only, сервер забороняє оновлення клієнтів навіть від користувачів, які мають SUPER. Дивіться опис системної змінної read_only для опису режиму лише для читання та інформації про взаємодію read_only та super_read_only.

Зміни super_read_only на головному сервері не копіюються на підлеглий сервери. Значення може бути встановлено на підлеглому сервері, незалежно від налаштування на ведучому.

Super_read_only додано в MySQL 5.7.8.

Чи слід встановлювати підлеглий реплікації MySQL лише для читання?

Так, вам краще запустити ведені сервери з доступними режимами R / O. Раніше привілейовані користувачі могли будь-коли змінювати дані таких підлеглих, але пізніше вони також отримали свою "регулятор" обмеження на виведення / виведення.

Чому це важливо - краще відмовитись від запису, ніж шкодувати з неправильним записом, який може ефективно зробити невідомого непридатним через просте вилучення даних або такі речі, як конфлікт ключів, який би порушив реплікацію (більше немає фактичного підлеглого знову).

Існує також програмне забезпечення, яке використовується для оркестрації / розбиття завантаження, яке враховує стан R / O серверів у пулах, які вони настроїли для правильної маршрутизації запитів серед цих серверів.

Це безпека. Використай це.

Проблема тут, включена MySQL 8.0, полягає в тому, що MySQL не змушує вас встановлювати read_only = ONпри виконанні start slaveкоманди. Чому проблема? Оскільки майже всі MySQL DBA використовують своїх рабів на RO, щоб запобігти пошкодженню даних, і завжди існує один dba, який випадково неправильно запускає SQL, що модифікує дані на підлеглому, або додаток, який не змінює його конф. Якщо я хочу писати на рабах, тому що у нього є кілька схем, і мені потрібно робити записи на цій схемі, тому read_onlyкоманда повинна бути більш розумною, і давайте робити це read_only for schema. Це може бути дуже корисно на серверах, що працюють з декількома майстрами, і рабами, які роблять aReplicate_Ignore_DB . Отже, на даний момент ви повинні зробити контроль вручну і бути дуже обережним.

Насолоджуйтесь.