mysql nie uruchomi się po zwiększeniu wielkości innodb_buffer_pool_size i innodb_log_file_size


18

Śledzę to rozwiązanie tutaj /programming/3927690/howto-clean-a-mysql-innodb-storage-engine/4056261#comment14041132_4056261 i próbowałem zwiększyć moje innodb_buffer_pool_sizedo 4G, a później 1G (również 1024M) w oprócz rozmiaru pliku dziennika, ale mysql nie rozpocznie się od tych wartości. Jeśli przywrócę to do 512M, mysql zaczyna działać dobrze.

Jak mogę to rozwiązać? Mój serwer ma 16 GB i zgodnie z sysinfo Webmina:

Real memory 15.62 GB total, 3.13 GB used

Tymczasem znalazłem również dziennik błędów:

120529 10:29:32 mysqld_safe mysqld z pliku pid /var/run/mysqld/mysqld.pid zakończony

120529 10:29:33 mysqld_safe Uruchamianie demona mysqld z bazami danych z / var / lib / mysql

120529 10:29:33 [Uwaga] Wtyczka „FEDERATED” jest wyłączona.

120529 10:29:33 InnoDB: Sterty pamięci InnoDB są wyłączone

120529 10:29:33 InnoDB: Muteksy i rw_locki używają atomowych wbudowań GCC

120529 10:29:33 InnoDB: Skompresowane tabele używają zlib 1.2.3

120529 10:29:33 InnoDB: Korzystanie z natywnego interfejsu AIO systemu Linux

120529 10:29:33 InnoDB: Inicjowanie puli buforów, rozmiar = 1,0G

120529 10:29:33 InnoDB: Zakończono inicjalizację puli buforów

InnoDB: Błąd: plik dziennika ./ib_logfile0 ma inny rozmiar 0 134217728 bajtów

InnoDB: niż podano w pliku .cnf 0 268435456 bajtów!


Czy możesz udostępnić dzienniki błędów dla tego ...
Abdul Manaf

Dzięki, udało mi się go znaleźć. Myślę, że będzie łatwiej. Powinienem również dodać na początku, że zwiększyłem również rozmiar pliku dziennika, aby dopasować wzrost puli buforów (dodałem teraz te informacje).
giorgio79

Ok @ giorgio79 ...
Abdul Manaf

Spróbuj usunąć plik (i) dziennika.
dezso

Czy najpierw usunąłeś rozmiar pliku dziennika? czy najpierw upuściłeś wszystkie bazy danych? Dodaj więcej informacji o tym, co dokładnie zrobiłeś?
ALH

Odpowiedzi:


19

Dwie odpowiedzi udzielone przez @RickJames i @drogart są w zasadzie środkami zaradczymi. (+1 za każdy).

Bezpośrednio z prezentowanego dziennika błędów ostatnie dwa wiersze mówią:

InnoDB: Błąd: plik dziennika ./ib_logfile0 ma inny rozmiar 0 134217728 bajtów

InnoDB: niż podano w pliku .cnf 0 268435456 bajtów! `

W tym momencie było oczywiste, że ustawiłeś rozmiar pliku dziennika_wpisu_do_pliku na 256 mln (268435456), my.cnfpodczas gdy dzienniki transakcji InnoDB ( ib_logfile0, ib_logfile1) wynosiły odpowiednio 128 mln (134217728). Patrząc wstecz na link do mojej odpowiedzi StackOverflow w swoim pytaniu, musiałeś wykonać następujące czynności:

Krok 01) Dodaj to do my.cnf:

[mysqld]
innodb_buffer_pool_size=4G
innodb_log_file_size=1G

Krok 02) Uruchom te polecenie w systemie operacyjnym

mysql -u... -p... -e"SET GLOBAL innodb_fast_shutdown = 1"
service mysql stop
rm -f /var/lib/mysql/ib_logfile*
service mysql start

Aby mieć pewność, co się dzieje, uruchom tail -fdziennik błędów. Zobaczysz komunikat informujący, kiedy tworzony jest każdy plik dziennika innodb.


Dzięki, tak, nie usunąłem ich najpierw. Chciałem tylko zobaczyć, jak zachowuje się mysql. Po wykonaniu kroku 3 ponowne uruchomienie działało.
giorgio79

1
Myślę, że nie należy usuwać plików dziennika, ale raczej przenieść je gdzie indziej i usunąć je później, gdy pomyślnie zmienisz rozmiar pliku dziennika. W przeciwnym razie będziesz mieć kłopoty, jeśli MySQL ulegnie awarii przed uruchomieniem service mysqld stop.
KajMagnus

4

Na podstawie błędu w dzienniku zgaduję, że to zrobiłeś:

  • zamknij mysql
  • edytowałem my.cnf, aby zmienić rozmiar pliku dziennika innodb
  • próbował uruchomić mysql (potem się nie udało)

Jeśli zmienisz rozmiar pliku dziennika, musisz usunąć stare pliki dziennika. Innodb nie uruchomi się pomyślnie, jeśli istniejące pliki nie pasują do określonego rozmiaru w pliku konfiguracyjnym. Jeśli przeniesiesz je w inne miejsce, innodb utworzy nowe pliki dziennika transakcji o odpowiednim rozmiarze podczas uruchamiania.

Zalecam przeniesienie starych plików do innego katalogu zamiast ich usuwania, dopóki serwer nie uruchomi się z nowymi plikami dziennika i wszystko będzie wyglądało OK.


3

Pula_ buforów powinna być ustawiona na około 70% dostępnej pamięci RAM, jeśli używasz tylko InnoDB.

Rozmiar kłody nie ma większego znaczenia. Optymalne jest ustawienie go w taki sposób, aby (Uptime * innodb_log_file_sile / Innodb_os_log_written) wynosił około 3600 (1 godzina).

Aby zmienić rozmiar dziennika, należy

  1. zamknij mysqld czysto
  2. usuń wartość z my.cnf (my.ini)
  3. usuń pliki dziennika
  4. retstart - nowe pliki dziennika zostaną odbudowane.

Dzięki, tak, to także poprawna odpowiedź. Mogłem zaakceptować tylko jeden. +1 to też.
giorgio79

1

W wartości podanej dla wielkości puli buforów może również występować problem . tak jak stało się w moim przypadku ...

Podczas zwiększania lub zmniejszania innodb_buffer_pool_sizeoperacja jest wykonywana w porcjach. Rozmiar porcji jest definiowany przez innodb_buffer_pool_chunk_sizeopcję konfiguracji, która ma domyślnie 128M. Aby uzyskać więcej informacji, zobacz Konfigurowanie rozmiaru porcji puli buforów InnoDB .

Rozmiar puli buforów musi zawsze być równy lub wielokrotność innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances. Jeśli skonfigurujesz innodb_buffer_pool_sizewartość, która nie jest równa lub wielokrotność innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances, wielkość puli buforów jest automatycznie dostosowywana do wartości, która jest równa lub jej wielokrotność innodb_buffer_pool_chunk_size * innodb_buffer_pool_instancesnie jest mniejsza niż określony rozmiar puli buforów.

W tym przykładzie innodb_buffer_pool_sizejest ustawiony na 8G i innodb_buffer_pool_instancesjest ustawiony na 16. innodb_buffer_pool_chunk_sizeto 128M, co jest wartością domyślną.

8G jest prawidłową innodb_buffer_pool_sizewartością, ponieważ 8G jest wielokrotnością innodb_buffer_pool_instances=16 * innodb_buffer_pool_chunk_size=128M, czyli 2G.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.