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

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?

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.

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.

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.

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

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]