Der MySQL-Server läuft mit der Option --read-only und kann diese Anweisung daher nicht ausführen.

Ich war in einer Besprechung, als ein Kollege anrief und berichtete, dass die Entwicklungsbibliothek nicht geschrieben werden konnte. Die Fehlermeldung lautete:

1209 - Der MySQL-Server läuft mit der Option --read-only und kann diese Anweisung daher nicht ausführen.

Im Allgemeinen gibt es zwei Gründe für diesen Fehler:

1. Stellen Sie eine Verbindung zur Slave-Datenbank her. Die Slave-Bibliothek ist grundsätzlich auf schreibgeschützt eingestellt.

2. Der read_only-Parameter der Masterdatenbank wird auf 1 geändert

Entwickler sind normale Benutzer und sollten nicht die Berechtigung haben, den Wert dieses Parameters zu ändern.

Der DBA ändert diesen Parameter nicht aktiv. Was genau ist also der Grund, warum die Entwicklungsbibliothek nicht geschrieben werden kann?

Zunächst konnten wir bestätigen, dass das Problem nicht bei den Entwicklern lag, da mehr als 200 Forschungs- und Entwicklungsmitarbeiter der Abteilung auf dieses Problem gestoßen waren.

Um das Problem zu lösen, fragen Sie zunächst den Wert des read_only-Parameters in der Masterdatenbank ab. Tatsächlich ist read_only auf 1 gesetzt.

Nach der manuellen Änderung auf 0 ist das Problem gelöst. Die Frage ist, warum read_only auf 1 gesetzt ist?

Die Lösungsschritte sind wie folgt:

mysql> wählen Sie @@read_only;

+-------------+

| @@Nur lesen |

+-------------+

| 1 |

+-------------+

1 Zeile im Satz (0,00 Sek.)

mysql> global schreibgeschützt auf 0 setzen;

Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

Beim Überprüfen des MySQL-Fehlerprotokolls habe ich die folgenden Informationen gefunden:

151231 13:55:11 mysqld_safe Anzahl der derzeit laufenden Prozesse: 0

151231 13:55:11 mysqld_safe mysqldneu gestartet

Dies zeigt, dass MySQL neu gestartet wurde. Was ist der Grund für den Neustart?

Ich habe das Systemprotokoll überprüft und den folgenden Fehler gefunden:

#tail -100f /var/log/nachricht

Dez 31 13:55:11 mysql2dev kernel: [8680] 500 8680 27084 92 3 0 0 bash

31. Dez 13:55:11 mysql2dev kernel: Out ofmemory: Kill process 12805 (mysqld) score 964 or sacrifice child

31. Dez 13:55:11 mysql2dev-Kernel: Killedprocess 12805, UID 500, (mysqld) total-vm:13146848kB, anon-rss:7870704kB,file-rss:16kB

31. Dez 13:55:11 mysql2dev-Kernel: rsyslogdinvoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

31. Dez 13:55:11 mysql2dev-Kernel: rsyslogdcpuset=/ mems_allowed=0-1

31. Dez 13:55:11 mysql2dev kernel: Pid:21035, comm: rsyslogd Nicht verdorben 2.6.32-358.el6.x86_64 #1

31. Dez 13:55:11 mysql2dev Kernel: CallTrace:

Anhand dieses Fehlers können wir erkennen, dass MySQL aufgrund eines Speicherüberlaufs neu gestartet wurde.

Nicht genügend Arbeitsspeicher: Prozess 12805 (mysqld)score 964 beenden oder Kindprozess opfern

Was also hat den Speicherverlust verursacht?

Nachdem ich die historischen Befehle des Systems überprüft hatte, stellte ich fest, dass ein Kollege gerade ein Backup durchführte. Das System stand zu diesem Zeitpunkt unter großem Druck und auf dem sekundären System war keine Swap-Partition eingerichtet. Die oben genannten Gründe führten zum Neustart von MySQL.

Tauschen: 0 0 0

Warum führt ein Neustart zu read_only=1? Vielleicht ist read_only in der Konfigurationsdatei eingestellt. Überprüfen Sie die Konfigurationsdatei.

#grep schreibgeschützt meine.cnf

schreibgeschützt = ein

Zu diesem Zeitpunkt wurde schließlich der Grund bekannt, warum die Entwicklungsumgebung plötzlich nicht geschrieben werden konnte.

Sie fragen sich vielleicht, warum die Hauptbibliothek read_only=on festlegt, da es sich ursprünglich um eine MMM-Umgebung handelte.

Nachdem die MMM-Umgebung entfernt wurde, setzen Sie read_only in der Konfigurationsdatei auf 0. Das Problem, dass die Entwicklungsbibliothek nicht geschrieben werden konnte, ist nun gelöst.

MySQL meldet einen Fehler: Der MySQL-Server läuft mit der Option --skip-grant-tables und kann daher diese Anweisung usw. nicht ausführen.

1. Melden Sie sich bei mysql an: mysql –u root –p

mysql> global schreibgeschützt auf 0 setzen;
(Deaktivieren Sie das schreibgeschützte Attribut der neuen Masterdatenbank.)

Berechtigungen leeren;

2. Ändern Sie die MySQL-Konfigurationsdatei my.cnf, die sich im Verzeichnis /etc befindet

Starten Sie den MySQL-Dienst neu: service mysqld restart

FEHLER 1290 (HY000): Der MySQL-Server läuft mit der Option --skip-grant-tables und kann daher nicht ausgeführt werden.

Dieser Fehler wurde beim Zurücksetzen des Kennworts während der Installation von MySQL 8.0.3 gemeldet. Der Grund dafür ist, dass Sie diesen Abschnitt zu /etc/my.cnf hinzufügen müssen, um MySQL ausführen zu können, wenn das Kennwort nicht festgelegt ist

#Passwortüberprüfung überspringen

Skip-Grant-Tabellen

Aber nachdem ich diesen Satz hinzugefügt hatte, meldete MySQL diesen Fehler erneut, was zu einer Endlosschleife führte. Schließlich fand ich eine Lösung.

Dies liegt daran, dass die Berechtigungen festgelegt, aber nicht aktualisiert wurden.

Zuerst ausführen

Berechtigungen leeren;

Führen Sie die SQL-Anweisung erneut aus und sie ist erfolgreich

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Ihr Passwort';