Nowa instalacja CentOS.
Uruchomiłem import dużej bazy danych (plik 2 GB sql) i miałem problem. Klient SSH wydawał się tracić połączenie, a import wydawał się zawieszać. Użyłem innego okna, aby zalogować się do mysql, a import wyglądał na martwy, utknął w konkretnej tabeli wierszy 3M.
Więc próbowałem
DROP DATABASE huge_db;
15-20 minut później nic. W innym oknie zrobiłem:
/etc/init.d/mysqld restart
Komunikat w oknie DROP DB: SERVER SHUTDOWN. Następnie zrestartowałem serwer fizyczny.
Zalogowałem się ponownie do mysql, sprawdziłem, a db wciąż tam jest, uruchomiłem
DROP DATABASE huge_db;
znowu i znowu czekam już około 5 minut.
Po raz kolejny jest to świeża instalacja. Jest huge_db
to jedyna db (inna niż systemowa dbs). Przysięgam, że upuściłem db tak duże wcześniej i szybko, ale może się mylę.
Pomyślnie upuściłem bazę danych. Zajęło to około 30 minut. Zauważ też, że myślę, że się pomyliłem, kiedy myślałem, że import mysqldump nie działa. Połączenie z terminalem zostało utracone, ale myślę, że proces nadal działał. Najprawdopodobniej zabiłem importowaną tabelę środkową (tabelę wierszy 3M) i prawdopodobnie 3/4 drogi przez całą bazę danych. Mylące było to, że „top” pokazywał mysql wykorzystujący tylko 3% pamięci, kiedy wydawało się, że powinien zużywać więcej.
Upuszczenie DB skończyło się 30 minutami, więc znowu mogłem nie musieć restartować serwera i prawdopodobnie mogłem tylko poczekać na zakończenie DROP, ale nie wiem, jak mysql zareagowałby na otrzymanie zapytania DROP dla ten sam db, który importuje przez mysqldump.
Pozostaje jednak pytanie, dlaczego DROP zajmuje ponad 30 minut, aby usunąć DROP z bazy danych o pojemności 2 GB, kiedy wszystko, co trzeba zrobić, to usunąć wszystkie pliki db i usunąć wszystkie odwołania do bazy danych z schematu_informacyjnego? O co tyle szumu?
DROP DATABASE
polecenia serwer nie będzie kontynuował, dopóki wszystkie połączenia nie zostaną zamknięte.Chociaż myślałem, że proces importowania wygasł, prawdopodobnie nadal trwa.
DROP DATABASE
Komenda prawdopodobnie czekał na bazie aby zakończyć importowanie zanim uciekł.Tak więc, zamiast
DROP DATABASE
zajmować dużo czasu, prawdopodobnie był to tylko import.Jeśli ktoś to czyta i próbuje anulować import bazy danych i upuścić bazę danych, zalecamy najpierw znaleźć PID (identyfikator procesu) dla importu i uruchomić go z innego terminalu:
... gdzie [PID] byłoby rzeczywistym PID dla procesu.
Powinieneś natychmiast zobaczyć zatrzymanie importu, jeśli drugi terminal jest nadal podłączony.
Możesz także uruchomić
SHOW PROCESSLIST
na karcie SQL phpMyAdmin. Wynikowa tabela pokazuje uruchomione procesy i kliknięcie „x” obok wiersza, który chcesz zabić, powinno załatwić sprawę.Następnie uruchomić
I wszystko powinno być czyste.
Inna odpowiedź sugeruje, że zabicie procesu w mysql jest lepsze niż robienie tego z zewnątrz. Nie przetestowałem tej odpowiedzi, ale brzmi to bardzo realistycznie. Dlatego zaznaczyłem to jako „zaakceptowaną odpowiedź” zamiast tej.
źródło
Spróbuj obciąć największe tabele w bazie danych youra, zanim ją upuścisz. Widziałem bardzo podobne zachowanie podczas pracy z archiwami MySQL ruchu zapory i to bardzo pomogło.
źródło
Pierwszą rzeczą, jaka przychodzi mi na myśl, jest status
Checking Permissions...
Kiedy wydajesz
DROP DATABASE mydb;
wszystko wewnątrz / var / lib / mysql / mydb, sprawdzane jest, czy istnieją uprawnienia systemu operacyjnego do prawa do usunięcia każdego pliku.Niektórzy uważają, że może pomóc zmniejszenie liczby użytkowników mysql
źródło
Napotkałem ten sam problem. Ale tym razem sprawdziłem pokaż listę procesów; powiedział, że sprawdzanie uprawnień przez dłuższy czas. Potem odkryłem, że mysqld_safe działa jako root, podczas gdy uprawnienia na poziomie folderu były tylko dla użytkownika mysql. Stąd zabiłem kwerendę, oczywiście zajęło dużo czasu mówiąc, że jest w stanie zabitym, ale czekałem, aż zareaguje, następnie zabiło kwerendę i zmieniłem uprawnienia na poziomie folderu do rootowania również poprzez dodanie go do grupy i chmod do 770. Następnie wykonałem ta sama baza danych upuść bla; to zadziałało dla mnie w 2 sekundy dla bazy danych 20 GB.
źródło