Lösen Sie das Problem, dass bei der Installation von MySQL unter Linux keine my.cnf-Datei in /etc vorhanden ist

Heute wollte ich den MySQL-Port ändern, habe jedoch festgestellt, dass in meinem /etc/-Verzeichnis keine my.cnf-Datei vorhanden war. Daher habe ich online nach einer Lösung gesucht.

Ich habe viele Blogs über das Fehlen von my.cnf unter Linux gelesen, in denen immer stand, ich solle my-medium.cnf nach etc verschieben und in my.cnf umbenennen, aber ich habe my-medium.cnf auch nicht. Später erfuhr ich, dass ab 5.7.18 die offizielle Version die Datei my-default.cnf nicht mehr im Binärpaket bereitstellt.

Weitere Einzelheiten finden Sie unter: https://dev.mysql.com/doc/refman/5.7/en/binary-installation.html

Wie ändern wir also die Portnummer? Tatsächlich müssen wir nur /etc/mysql/mysql.conf.d ändern.

Ergänzung: Beim Start von mysql erfolgt eine Meldung, dass /etc/my.cnf ignoriert wird.

Heute habe ich mich mit einem Testentwickler an einem Problem beteiligt und dabei festgestellt, dass beim Start einer MySQL-Instanz ein Fehler aufgetreten ist. Der Vorgang verlief wie folgt:

Es wird festgestellt, dass die MySQL-Instanz geschlossen ist. Beim Ausführen des Befehls zum Starten der MySQL-Instanz wird eine Warnung angezeigt:

# Dienst mysql.server starten
Warnung: Die allgemein beschreibbare Konfigurationsdatei „/etc/my.cnf“ wird ignoriert
MySQL wurde erfolgreich gestartet!

Beachten Sie das MySQL-Startprotokoll, das Folgendes zeigt:

151014 11:39:24 mysqld_safe Starte mysqld-Daemon mit Datenbanken aus /data/mysql/data
Warnung: Die allgemein beschreibbare Konfigurationsdatei „/etc/my.cnf“ wird ignoriert

Es bedeutet wahrscheinlich, dass die Berechtigungen global schreibbar sind und jeder Benutzer schreiben kann. MySQL befürchtet, dass diese Datei von anderen Benutzern böswillig geändert werden könnte, und ignoriert daher diese Konfigurationsdatei. Auf diese Weise kann MySQL nicht heruntergefahren werden.

Beim Abfragen der Konfiguration in der MySQL-Datenbank wird derzeit festgestellt, dass einige in my.cnf konfigurierte Parameter in der MySQL-Instanz nicht wirksam sind.

Dies liegt daran, dass /etc/my.cnf ebenfalls auf die Berechtigungen 777 geändert wurde:

# ls -la /etc/my.cnf
-rwxrwxrwx 1 root root 1120 31. Juli 10:28 /etc/my.cnf

/etc/my.cnf hat zu viele Berechtigungen, was dazu führt, dass die Instanz nicht gestartet oder heruntergefahren werden kann. Es muss auf 644 geändert werden. Der Vorgang ist wie folgt:

# ls -la /etc/my.cnf
-rwxrwxrwx 1 root root 1120 31. Juli 10:28 /etc/my.cnf
# 
# 
# chmod 644 /etc/my.cnf
# 
# ls -la /etc/my.cnf
-rw-r--r-- 1 root root 1120 31. Juli 10:28 /etc/my.cnf
#

Bestätigen Sie /etc/my.cnf und starten Sie die Instanz neu:

151014 14:05:54 mysqld_safe mysqld aus PID-Datei /data/mysql/data/yq-xg-dev122.pid beendet
151014 14:06:08 mysqld_safe Starte mysqld-Daemon mit Datenbanken aus /data/mysql/data
151014 14:06:08 [Hinweis] Plugin „FEDERATED“ ist deaktiviert.
151014 14:06:08 InnoDB: Der InnoDB-Speicherheap ist deaktiviert
151014 14:06:08 InnoDB: Mutexes und rw_locks verwenden atomare Builtins von GCC
151014 14:06:08 InnoDB: Komprimierte Tabellen verwenden zlib 1.2.3
151014 14:06:08 InnoDB: Linux natives AIO verwenden
151014 14:06:08 InnoDB: Pufferpool wird initialisiert, Größe = 128,0 M
151014 14:06:08 InnoDB: Initialisierung des Pufferpools abgeschlossen
151014 14:06:08 InnoDB: Das am höchsten unterstützte Dateiformat ist Barracuda.
151014 14:06:08 InnoDB: Warte auf den Start der Hintergrund-Threads
151014 14:06:09 InnoDB: 1.1.8 gestartet; Protokollsequenznummer 18872844901
151014 14:06:09 [Warnung] „proxies_priv“-Eintrag „@ root@xinge122“ wird im Modus „-skip-name-resolve“ ignoriert.
151014 14:06:09 [Hinweis] Event Scheduler: 0 Ereignisse geladen
151014 14:06:09 [Hinweis] /usr/local/mysql/bin/mysqld: bereit für Verbindungen.
Version: „5.5.19-log“ Socket: „/tmp/mysql.sock“ Port: 3306 MySQL Community Server (GPL)

Sie können sehen, dass die MySQL-Instanz normal gestartet werden kann, nachdem Sie die Berechtigungen für /etc/my.cnf auf „normal“ geändert haben.

Aus diesem Fall können folgende Inspirationen gewonnen werden:

Das Ändern der Berechtigungen von Verzeichnissen und Dateien im Stammverzeichnis des Linux-Betriebssystems ist sehr gefährlich.

Wenn beispielsweise die Berechtigungen des Verzeichnisses /etc/ssh geändert werden, kann SSH nicht verwendet werden. Wenn die Dateien /etc/security oder /etc/init.d/sshd geändert werden, kann sich der Root-Benutzer nicht beim System anmelden.

Daher müssen Sie auf die Systemberechtigungen achten, insbesondere auf die Dateiberechtigungen im Verzeichnis /etc/, die nicht einfach so geändert werden können.

Sowohl Entwicklung als auch Betrieb und Wartung müssen standardisiert werden und direkte Vorgänge als Root-Benutzer sollten so weit wie möglich vermieden werden. Der Speicherort von Software und Anwendungen sollte ebenfalls in einem separaten Verzeichnis abgelegt werden und jede Anwendung sollte von einem separaten Benutzer bedient werden.

Ändern Sie Systemdateien nicht leichtfertig, insbesondere ändern Sie nicht leichtfertig Systemdateien, die mit /etc/ in Zusammenhang stehen. Wenn Sie sie ändern möchten, können Sie sie zuerst testen und sicherstellen, dass keine Probleme auftreten, bevor Sie Änderungen vornehmen.

Das Obige ist meine persönliche Erfahrung. Ich hoffe, es kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden. Sollten dennoch Fehler oder unvollständige Überlegungen vorliegen, freue ich mich über eine Korrektur.