Jak bezpiecznie zmienić zmienną innodb MySQL 'innodb_log_file_size'?

105

Więc jestem całkiem nowy w tuningu InnoDB. Powoli zmieniam tabele (w razie potrzeby) z MyIsam na InnoDB. Mam około 100 MB w innodb, więc zwiększyłem innodb_buffer_pool_sizezmienną do 128 MB:

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

Kiedy poszedłem zmienić innodb_log_file_sizewartość (przykład my.cnf na stronie konfiguracji innodb mysql komentuje, aby zmienić rozmiar pliku dziennika na 25% wielkości bufora. Teraz mój plik my.cnf wygląda następująco:

# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M

Po ponownym uruchomieniu serwera pojawia się ten błąd:

110216 9:48:41 InnoDB: Inicjalizacja puli buforów, rozmiar = 128.0M
110216 9:48:41 InnoDB: Zakończona inicjalizacja puli buforów
InnoDB: Błąd: plik dziennika ./ib_logfile0 ma inny rozmiar 0 5242880 bajtów
InnoDB: niż określono w plik .cnf 0 33554432 bajtów!
110216 9:48:41 [BŁĄD] Funkcja inicjująca wtyczki „InnoDB” zwróciła błąd.
110216 9:48:41 [BŁĄD] Rejestracja wtyczki „InnoDB” nie powiodła się.

Więc moje pytanie: czy bezpiecznie jest usunąć stare log_files, czy też istnieje inna metoda zmiany innodb_log_file_sizezmiennej?

Derek Downey
źródło
1
Wystarczy skomentować rozmiar pliku dziennika_wpisu w pliku my.ini .....
5
hmm, dlaczego miałbym chcieć to skomentować, aby użyć wartości domyślnej, gdy próbuję ją zmienić z wartości domyślnej?
Derek Downey,
Tak, komentując linię innodb_log_file_size jego działa. Dzięki.
muhammad umar farooq frank
2
@muhammadumarfarooqfrank Oczywiście to działa - ponieważ nie zmieniasz już wartości zmiennej, dlatego cały punkt jest dyskusyjny. Chciałbym, aby istniał sposób na głosowanie za komentarzami.
dr01

Odpowiedzi:

83

Tak, można bezpiecznie usunąć plik dziennika po zamknięciu mysqld

W świetle tego wystarczy wykonać następujące czynności:

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

Uruchomienie mysqld odtworzy ib_logfile0iib_logfile1

Spróbuj !!!

AKTUALIZACJA 2011-10-20 16:40 EDT

Czyści strony wszystkich danych w puli buforów InnoDB przed ponownym wykonaniem plików dziennika, należy ustawić tę opcję na około godzinę przed wyłączeniem:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Domyślnie innodb_max_dirty_pages_pct to 75 (MySQL 5.5+) lub 90 (przed MySQL 5.5). Ustawienie wartości zero powoduje, że liczba brudnych stron jest mniejsza niż 1% puli buforów InnoDB. Performing service mysql stopi tak to robi. Ponadto zamknięcie zakończy wszystkie pozostałe elementy w dzienniku ponownych operacji. Aby zachować tę opcję, po prostu dodaj ją do /etc/my.cnf:

[mysqld]
innodb_max_dirty_pages_pct = 0

AKTUALIZACJA 2013-04-19 16:16 EDT

Trochę zaktualizowałem swoją odpowiedź za pomocą innodb_fast_shutdown, ponieważ kiedyś zrestartowałem mysql i zatrzymałem mysql, aby to zrobić. Teraz ten jeden krok jest niezbędny, ponieważ każda niezatwierdzona transakcja może zawierać inne ruchome części w dziennikach transakcji InnoDB i poza nimi ( patrz Infrastruktura InnoDB ).

Należy pamiętać, że ustawienie innodb_fast_shutdown na 2 również wyczyści dzienniki, ale więcej ruchomych części nadal istnieje i zostanie wybranych podczas odzyskiwania po awarii podczas uruchamiania mysqld. Ustawienie 0 jest najlepsze.

RolandoMySQLDBA
źródło
1
Ładna odpowiedź, a aktualizacja też jest świetna. Moją jedyną propozycją byłoby KOPIOWANIE plików ib_log do innej lokalizacji na wypadek, gdyby coś poszło nie tak. Pomoże Ci to dowiedzieć się, jak zmienić
Justin Noel
5
Pracowałem również dla mnie, ALE: interfejs konsoli Linux może być mylący - uruchomienie mysqld zajmuje dużo czasu, jeśli ustawisz duży plik dziennika (kilkaset MB lub więcej). Interfejs użytkownika konsoli pokazuje kropki, a następnie pokazuje „nie powiodło się!”, Ale tak naprawdę MySQL wciąż się uruchamia. Poczekaj i czytaj dalej plik dziennika (lub monitoruj plik dziennika za pomocą „tail -f [log-file]”), aż zobaczysz „mysqld: gotowy do połączeń”. i oba pliki dziennika przydzielone na dysku.
f055
2
OSTRZEŻENIE!! krok 3 nie działał dla mnie, a moje serce prawie się zatrzymało, gdy zobaczyłem, że mysql ładuje się bez InnoDB, musiałem zatrzymać mysql i usunąć je ręcznie i ponownie uruchomić MySQL. dwie porady: 1.
wykonaj
2
Peeyush ma rację. Nawet dokumentacja mysql zaleca tworzenie kopii zapasowych plików dziennika na wypadek, gdyby coś poszło nie tak
Greg
1
@Greg właśnie dlatego używam SET GLOBAL innodb_fast_shutdown = 0;. Gdy MySQL zamyka się, wszystko transakcyjne jest usuwane ze wszystkich ruchomych części, w tym dzienników ponownych (ib_logfile0 i ib_logfile1). Można je zatrzymać. Mam jeszcze problemy z całkowicie opróżnionymi logami.
RolandoMySQLDBA
31

Zamiast tego poleciłbym oficjalną metodę , którą tutaj odtwarzam dla wygody:

Aby zmienić liczbę lub rozmiar plików dziennika InnoDB w MySQL 5.6.7 lub wcześniejszym , skorzystaj z poniższych instrukcji. Procedura, którą należy zastosować, zależy od wartości innodb_fast_shutdown, która określa, czy należy w pełni zaktualizować systemowy obszar tabel przed operacją zamykania:

  • Jeśli innodb_fast_shutdown nie jest ustawiony na 2: Zatrzymaj serwer MySQL i upewnij się, że wyłącza się bez błędów, aby upewnić się, że w dzienniku ponawiania nie ma informacji o zaległych transakcjach. Skopiuj stare pliki dziennika ponawiania do bezpiecznego miejsca, na wypadek, gdyby coś poszło nie tak podczas zamykania i potrzebujesz ich do odzyskania obszaru tabel. Usuń stare pliki dziennika z katalogu plików dziennika, edytuj plik my.cnf, aby zmienić konfigurację pliku dziennika, i ponownie uruchom serwer MySQL. mysqld widzi, że żadne pliki dziennika InnoDB nie istnieją podczas uruchamiania i tworzy nowe.

  • Jeśli innodb_fast_shutdown jest ustawiony na 2: Ustaw innodb_fast_shutdown na 1:

mysql> SET GLOBAL innodb_fast_shutdown = 1;

Następnie postępuj zgodnie z instrukcjami w poprzednim punkcie.

Począwszy od MySQL 5.6.8 , ustawienie innodb_fast_shutdown nie jest już istotne przy zmianie liczby lub rozmiaru plików dziennika InnoDB. Ponadto nie musisz już usuwać starych plików dziennika, chociaż nadal możesz chcieć skopiować stare pliki dziennika w bezpieczne miejsce, jako kopię zapasową. Aby zmienić liczbę lub rozmiar plików dziennika InnoDB, wykonaj następujące czynności:

  1. Zatrzymaj serwer MySQL i upewnij się, że wyłącza się bez błędów.

  2. Edytuj plik my.cnf, aby zmienić konfigurację pliku dziennika. Aby zmienić rozmiar pliku dziennika, skonfiguruj innodb_log_file_file_size. Aby zwiększyć liczbę plików dziennika, skonfiguruj innodb_log_files_in_group.

  3. Uruchom ponownie serwer MySQL.

Jeśli InnoDB wykryje, że rozmiar innodb_log_file_file różni się od rozmiaru pliku dziennika ponownego, zapisze punkt kontrolny dziennika, zamknie i usunie stare pliki dziennika, utworzy nowe pliki dziennika o żądanym rozmiarze i otworzy nowe pliki dziennika.

RandomSeed
źródło
To dobra odpowiedź jako aktualizacja tego pytania. +1 !!!
RolandoMySQLDBA
2
To nie jest „aktualizacja”. Te strony podręcznika już dawno istniały. Zawsze zalecam informacje z pierwszej ręki z podręcznika (jeden z najlepszych podręczników), zamiast wymyślać koło i powielać informacje (jest to coś, czego DBA najbardziej nienawidzi).
RandomSeed
Jest to preferowana metoda od MySQL 5.6. Jeśli nadal działasz na wersji wcześniejszej niż 5.6, to nie zadziała.
Derek Downey
20

innodb_buffer_pool_size- wystarczy zmienić my.cnf( my.ini) i zrestartować mysqld.

innodb_log_file_sizejest mniej krytyczny. Nie zmieniaj go, chyba że istnieje ku temu powód. Roland podał kroki , ale martwi mnie jeden aspekt ... Nie wiem, czy pierwsze dwa kroki są ważne; wygląda na to, że mogą to być:

  1. set innodb_fast_shutdown = OFF
  2. uruchom ponownie mysql
  3. zatrzymać mysql
  4. usuń pliki dziennika
  5. uruchom mysql

Pliki dziennika śledzą niedokończone sprawy; „ innodb_fast_shutdown” mówi, aby poradzić sobie z tymi problemami po ponownym uruchomieniu. Czy usunięcie plików może spowodować utratę informacji?

Nowe wersje poprawiły: (więcej dyskusji w komentarzach)

  • 5.6 Pozwala na innodb_log_file_size> 4 GB
  • 5.6 innodb_log_file_sizemożna zmienić bez uprzedniego usunięcia iblog *
  • 5.7 pozwala na dynamiczne zmiany rozmiaru innodb_buffer_pool_size

Czy powinienem zmienić log_file_size?

Służy GLOBAL STATUSdo obliczania liczby minut poprzedzających cykle dziennika.

Uptime / 60 * innodb_log_file_size / Innodb_os_log_written`

Jeśli jest to znacznie mniej niż 60 (minuty), może pomóc zwiększyć rozmiar_pliku_logu. Jeśli jest to znacznie więcej, pliki dziennika marnują miejsce na dysku. Ta „1 godzina” jest raczej dowolna, więc jeśli jesteś blisko niej, nie zawracaj sobie głowy zmienianiem rozmiaru pliku_logu.

Pozostaw innodb_log_files_in_groupdomyślnie 2.

Rick James
źródło
+1 twoja obawa wydaje się być poparta przez doktorów
Jack Douglas
Spojrzałem na tę odpowiedź i podoba mi się pierwszy wiersz. Zwykle miałem klientów, którzy wprowadzali mysql w --skip-networkingcelu uniknięcia tych zmian w ostatniej chwili. Twój pierwszy wiersz (set innodb_fast_shutdown = OFF) eliminuje to. +1 !!!
RolandoMySQLDBA
1
Dzięki za opinie. Nowi czytelnicy mogą tego nie potrzebować. W 5.6.8 , innodb_log_file_sizezostała wzmocniona, aby umożliwić zmianę go bez zdejmowania iblog plików.
Rick James
Czy masz na myśli „bardziej krytyczny”, a nie „mniej krytyczny”?
Igor
@Igor - Nie. Jeśli rozmiar pliku_logu jest zbyt mały, pojawią się dodatkowe zakłócenia we / wy. Rzadko to widzę. Jeśli masz go za dużo, po prostu marnujesz miejsce na dysku. Celem ustawienia jest przejście w ciągu godziny. Ale 10 minut w porównaniu do 10 godzin - żadne nie ma większego znaczenia. więcej ...
Rick James
1

Po zalogowaniu się do mysql wpisz następujące polecenia:

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

Otrzymasz dwie liczby. Najpierw dostaniesz jeden, a następnie poczekaj minutę. Dostaniesz inny.

Powiedzmy, że pierwszy to 3.456.718.123, a drugi to 4.098.873.134

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

Wynik to = 13,856 MB

Masz dwa pliki dziennika. Podziel go przez dwa, a otrzymasz liczbę blisko 7 000 MB. Dla pewności ustaw rozmiar pliku dziennika na 8 GB

Linux Newbie
źródło
1
Nie jest (przynajmniej dla mnie) oczywiste, że to faktycznie odpowiada na pytanie. Wydaje się to sugerować alternatywny rozmiar pliku dziennika, a nie jak bezpiecznie zmienić rozmiar pliku dziennika.
RDFozz
1
@RDFozz masz rację. To nie odpowiada, jak zmienić rozmiar pliku dziennika. To pytanie zawiera odpowiedzi na pytanie, jak wymyślić liczbę, aby ustawić rozmiar pliku dziennika_wpisu_log. Odpowiedziałem już na takie pytanie pięć lat temu (Zobacz podtytuł Log File Sizew dba.stackexchange.com/questions/23189/... )
RolandoMySQLDBA
Chciałem tylko pomóc: / Wiem jednak, że nie jest to dokładna odpowiedź.
Linux Newbie
-4

chown mysql: mysql -R / etc / mysql / var / lib / mysql && cd / var / lib / mysql && rm -f ib_logfile * && service mysql restart || usługa mysql restart

Wypróbuj, na pewno działa [testowany na Debianie 6]

Gregory
źródło
2
Nie gwarantuje to czystego wyłączenia. Może to działać w przeciętnym przypadku na serwerze z niewielkim obciążeniem, ale nie jest to zalecane, jeśli zależy Ci na integralności bazy danych.
Emil Vikström