Wie ändere ich die MySQL InnoDB -Variable 'innoDB_log_file_size' sicher?

https://dba.stackexchange.com/questions/1261

16-10-2019
|

Frage

Ich bin also ziemlich neu im Tuning InnoDB. Ich wechsle langsam Tabellen (falls nötig) von MyISAM nach InnoDB. Ich habe ungefähr 100 MB in InnoDB, also habe ich das erhöht innodb_buffer_pool_size Variable zu 128 MB:

mysql> show variables like 'innodb_buffer%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)

Als ich das ändern wollte, um das zu ändern innodb_log_file_size Wert (Beispiel my.cnf on Mysqls InnoDB -Konfigurationsseite Kommentare, um die Größe der Protokolldatei auf 25% der Puffergröße zu ändern. Jetzt sieht mein my.cnf so aus:

# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M

Wenn ich den Server neu starte, erhalte ich diesen Fehler:

110216 9:48:41 INNODB: Initialisieren von Pufferpool, Größe = 128,0 m
110216 9:48:41 InnoDB: Abgeschlossene Initialisierung des Pufferpools
InnoDB: Fehler: Protokolldatei ./ib_logfile0 hat unterschiedliche Größe 0 5242880 Bytes
InnoDB: als in der .cnf -Datei 0 33554432 Bytes angegeben!
110216 9:48:41 [Fehler] Plugin 'InnoDB' Init -Funktion zurückgegebener Fehler.
110216 9:48:41 [Fehler] Plugin 'InnoDB' Registrierung als Speichermotor fehlgeschlagen.

Meine Frage: Ist es sicher, die alten log_files zu löschen, oder gibt es eine andere Methode, um die zu ändern innodb_log_file_size Variable?

Lösung

Ja, es ist sicher, die Protokolldatei zu löschen, sobald MySQLD heruntergefahren wurde

Führen Sie vor diesem Hintergrund einfach die folgenden Schritte aus:

mysql -uroot -p... -e"SET GLOBAL innodb_fast_shutdown = 0"
service mysql stop
mv /var/lib/mysql/ib_logfile[01] /tmp
service mysql start

Das Starten von MySQLD wird nachbilden ib_logfile0 und ib_logfile1

Versuche es !!!

Update 2011-10-20 16:40 EDT

Vor der Wiederholung der Protokolldateien sollten Sie diese Option etwa 1 Stunde vor dem Herunterdown festlegen:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Standardmäßig, INNODB_MAX_DIRTY_PAGES_PCT ist 75 (MySQL 5.5+) oder 90 (vor MySQL 5.5). Wenn Sie dies auf Null setzen, wird die Anzahl der schmutzigen Seiten unter 1% des InnoDB -Pufferpools gehalten. Leistung service mysql stop tut das trotzdem. Darüber hinaus wird eine Abschaltung alle verbleibenden Elemente im Redo -Protokoll abgeschlossen. Um diese Option zu halten, fügen Sie sie einfach zu /etc/my.cnf hinzu:

[mysqld]
innodb_max_dirty_pages_pct = 0

Update 2013-04-19 16:16 EDT

Ich habe meine Antwort ein bisschen mehr aktualisiert mit innodb_fast_shutdown Weil ich MySQL neu gestartet habe und MySQL dazu gestoppt habe, dies zu tun. Jetzt ist dieser Einschritt von entscheidender Bedeutung, da jede Transaktion nicht mehr bewegliche Teile innerhalb und außerhalb der InnoDB-Transaktionsprotokolle haben kann (Siehe InnoDB -Infrastruktur).

Bitte beachten Sie diese Einstellung innodb_fast_shutdown bis 2 würden auch die Protokolle reinigen, aber es gibt immer noch mehr bewegende Teile und werden während des Starts von MySQLD bei der Absturzwiederherstellung ausgewählt. Die Einstellung von 0 ist am besten.

Andere Tipps

Ich würde stattdessen das empfehlen offizielle Methode, was ich hier aus Bequemlichkeit reproduziere:

So ändern Sie die Nummer oder die Größe von InnoDB -Protokolldateien in MySQL 5.6.7 oder früher, Verwenden Sie die folgenden Anweisungen. Die zu verwendende Prozedur hängt vom Wert von innoDB_Fast_Shutdown ab, der feststellt, ob das System Tablespace vor einem Abschaltungsvorgang vollständig aktuell ist oder nicht:

Wenn innodb_fast_shutdown nicht auf 2 gesetzt ist: Stoppen Sie den MySQL -Server und stellen Sie sicher, dass er ohne Fehler geschlossen wird, um sicherzustellen, dass keine Informationen für ausstehende Transaktionen im Wiederholungsprotokoll vorhanden sind. Kopieren Sie die alten Redo -Protokolldateien an einen sicheren Ort, falls während des Herunterfahrens etwas schief gelaufen ist und Sie sie benötigen, um den Tablespace wiederherzustellen. Löschen Sie die alten Protokolldateien aus dem Verzeichnis der Protokolldatei, bearbeiten Sie my.cnf, um die Konfiguration der Protokolldatei zu ändern, und starten Sie den MySQL -Server erneut. MySQLD sieht, dass beim Start keine InnoDB -Protokolldateien vorhanden sind und neue erstellt.

Wenn innodb_fast_shutdown auf 2 gesetzt ist: Setzen Sie innoDB_Fast_Shutdown auf 1:

mysql> SET GLOBAL innodb_fast_shutdown = 1;

Befolgen Sie dann die Anweisungen im vorherigen Element.

Ab MySQL 5.6.8, Die Einstellung innodb_fast_shutdown ist bei Ändern der Nummer oder der Größe von InnoDB -Protokolldateien nicht mehr relevant. Darüber hinaus müssen Sie nicht mehr alte Protokolldateien entfernen, obwohl Sie die alten Protokolldateien möglicherweise weiterhin als Sicherung an einen sicheren Ort kopieren möchten. Führen Sie die folgenden Schritte aus, um die Anzahl oder Größe von InnODB -Protokolldateien zu ändern:

Stoppen Sie den MySQL -Server und stellen Sie sicher, dass er ohne Fehler geschlossen wird.

Bearbeiten Sie my.cnf, um die Konfiguration der Protokolldatei zu ändern. Um die Größe der Protokolldatei zu ändern, konfigurieren Sie innodb_log_file_size. Um die Anzahl der Protokolldateien zu erhöhen, konfigurieren Sie innodb_log_files_in_group.

Starten Sie den MySQL -Server erneut.

Wenn InnoDB feststellt, dass sich die innodb_log_file_size von der Größe der Wiederherstellung der Protokolldatei unterscheidet, schreibt er einen Protokoll -Checkpoint, schließt und entfernen die alten Protokolldateien, erstellen Sie neue Protokolldateien an der angeforderten Größe und öffnen Sie die neuen Protokolldateien.

innodb_buffer_pool_size - einfach ändern my.cnf (my.ini) und starten Sie Mysqld neu.

innodb_log_file_size ist weniger kritisch. Ändern Sie es nicht, es sei denn, es gibt einen Grund dafür. Roland bereitgestellt die Schritte, Aber ein Aspekt macht mich Sorgen ... Ich weiß nicht, ob die ersten beiden Schritte wichtig sind; Es scheint, als könnten sie sein:

set innodb_fast_shutdown = OFF
Starten Sie MySQL neu
Stoppen Sie MySQL
Entfernen Sie die Protokolldateien
Starten Sie MySQL

Die Protokolldateien verfolgen das unvollendete Geschäft. "innodb_fast_shutdown"Sagt, mit diesem Zeug umzugehen nach neu starten. Das Entfernen der Dateien kann also Informationen verlieren?

Neue Versionen haben die Dinge verbessert: (Weitere Diskussion in Kommentaren)

5.6 erlaubt innodb_log_file_size > 4 GB
5.6 innodb_log_file_size kann geändert werden, ohne zuerst Iblog* zu entfernen*
5.7 ermöglicht die dynamische Änderung innodb_buffer_pool_size

Soll ich log_file_size ändern?

Verwenden GLOBAL STATUS So berechnen Sie die Anzahl der Minuten vor den Log -Zyklen.

Uptime / 60 * innodb_log_file_size / Innodb_os_log_written`

Wenn es viel ist weniger als 60 (Minuten) kann es helfen, log_file_size zu erhöhen. Wenn es viel mehr ist, verschwenden die Protokolldateien den Speicherplatz. Diese "1 Stunde" ist eher willkürlich. Wenn Sie also in der Nähe sind, müssen Sie sich nicht die Mühe machen, die log_file_size zu ändern.

Verlassen innodb_log_files_in_group im Standard von 2.

Wenn Sie sich bei MySQL anmelden, geben Sie diese Befehle ein:

pager grep seq;
show engine innodb status \G select sleep(60); show engine innodb status \G

Sie erhalten zwei Zahlen. Zuerst bekommst du einen und wartest dann eine Minute. Sie werden einen anderen bekommen.

Angenommen, der erste ist 3.456.718.123 und der zweite ist 4.098.873.134

Jetzt (4.098.873.134-3.856.718.123)*60/1024/1024

Das Ergebnis ist = 13,856 MB

Sie haben zwei Protokolldateien. Also teilt es um zwei und Sie erhalten eine Zahl nahe 7.000 MB. Setzen Sie Ihre Protokolldateigröße 8 GB fest, um sicher zu sein

Chown MySQL: Mysql -r/etc/mysql/var/lib/mysql && cd/var/lib/mysql && rm -f ib_logfile* && service mysql restart || Service MySQL Neustart

Versuchen Sie es, garantiert zu arbeiten [getestet an Debian 6

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit dba.stackexchange