Mam replikację uruchomioną na Percona Server 5.5, postępując zgodnie z tym przewodnikiem i zastanawiałem się, czy powinienem dodać read-only=1do mojego urządzenia podrzędnego, my.cnfaby był tylko do odczytu?

Przewodnik konfiguruje replikację dla tabeli mysql, aby użytkownicy byli replikowani, ale przede wszystkim używam slave'a do robienia mysqldump, aw nagłych wypadkach rekonfiguruję go jako master, więc nie sądzę, że potrzebujemy (lub powinniśmy) włączyć zapis na ciągle?

Gdy Slave jest tylko do odczytu , nie jest w 100% chronione przed światem.

Według dokumentacji MySQL na read-only

Ta zmienna jest domyślnie wyłączona. Po włączeniu serwer nie zezwala na żadne aktualizacje, z wyjątkiem użytkowników posiadających uprawnienia SUPER lub (na serwerze podrzędnym) z aktualizacji wykonywanych przez wątki podrzędne. W konfiguracjach replikacji przydatne może być włączenie read_only tylko na serwerach slave, aby upewnić się, że slave akceptują aktualizacje tylko z serwera master, a nie od klientów.

Zatem każdy z uprawnieniami SUPER może czytać i pisać do takiego Slave ...

Upewnij się, że wszyscy nieuprzywilejowani użytkownicy nie mają uprawnienia SUPER.

Jeśli chcesz cofnąć wszystkie uprawnienia SUPER za jednym razem, uruchom to na Master i Slave:

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

W odniesieniu do Slave, to zarezerwuje SUPER przywilej do sprawiedliwego rooti zapobiegnie robieniu zapisów, od których w przeciwnym razie byliby ograniczeni.

AKTUALIZACJA 28.08.2015, 17:39 EDT

Niedawno dowiedziałem się, że MySQL 5.7 wprowadzi super_read_only .

To zatrzyma SUPER użytkowników na ich ścieżkach, ponieważ 5.7 Dokumenty mówią

Jeśli zmienna systemowa read_only jest włączona, serwer zezwala na aktualizacje klienta tylko od użytkowników, którzy mają uprawnienia SUPER. Jeśli zmienna systemowa super_read_only jest również włączona, serwer zabrania aktualizacji klienta nawet użytkownikom, którzy mają SUPER. Zobacz opis zmiennej systemowej read_only, aby zapoznać się z opisem trybu tylko do odczytu oraz informacjami na temat interakcji między read_only i super_read_only.

Zmiany w super_read_only na serwerze głównym nie są replikowane na serwerach podrzędnych. Wartość można ustawić na serwerze podrzędnym niezależnie od ustawień na urządzeniu głównym.

super_read_only został dodany w MySQL 5.7.8.

Czy slave replikacji MySQL powinien być ustawiony na tylko do odczytu?

Tak, lepiej uruchomić serwery podrzędne z dostępnymi trybami R / O. Wcześniej uprzywilejowani użytkownicy i tak mogli modyfikować dane takiego urządzenia podrzędnego, ale później otrzymali również „pokrętło” ograniczenia R / O.

Dlaczego jest to ważne - lepiej zawodzić przy zapisie niż żałować przy niewłaściwym zapisie, które może skutecznie uczynić slave bezużytecznym z powodu zwykłego pomieszania danych lub takich rzeczy jak konflikt kluczy, który mógłby przerwać replikację (nigdy więcej rzeczywistego slave).

Istnieje również oprogramowanie używane do koordynowania / podziału obciążenia, które bierze pod uwagę status R / O serwerów w pulach, które skonfigurowali dla prawidłowego routingu żądań między tymi serwerami.

To jest bezpieczeństwo. Użyj tego.

Problem tutaj, w tym MySQL 8.0, polega na tym, że MySQL nie zmusza cię do ustawienia read_only = ONpodczas wykonywania start slavepolecenia. Dlaczego jest problem? Ponieważ prawie wszystkie bazy danych MySQL DBA używają swoich slaveów na RO, aby zapobiec uszkodzeniu danych, i zawsze istnieje jeden dba, który przypadkowo nieprawidłowo uruchamia SQL, który modyfikuje dane na slave, lub aplikację, która nie zmieni jego konf. Jeśli chcę pisać na niewolnikach, ponieważ ma kilka schematów i muszę pisać na tym schemacie, więc read_onlypolecenie musi być bardziej inteligentne i pozwól nam zrobić read_only for schema. Może to być bardzo przydatne na serwerach i masterach podrzędnych, które wykonują Replicate_Ignore_DB. Więc na razie musisz ręcznie kontrolować i być bardzo ostrożnym.

Cieszyć się.