2008-09-29 18 views
11

mysql5.0 z parą baz danych "A" i "B", obie z dużymi tabelami innodb. "usuń bazę danych A;" zawiesza bazę danych "B" na kilka minut. W tym momencie nic nie używa litery "A", więc dlaczego ta operacja jest tak intensywna?"drop database" mysql wymaga czasu - dlaczego?

Punkty bonusowe: biorąc pod uwagę, że używamy "A", prześlij dane do "B", a następnie przejdź do "B", jak możemy to zrobić szybciej? Upuszczanie baz danych nie jest czymś, co zwykle trzeba robić przez cały czas, więc jest to trochę poza listami przebojów.

+0

Miałem podobny problem, ale inne bazy danych działały. Rozwiązaniem było zabicie wszystkich innych procesów korzystających z tej bazy danych, ponieważ blokowały ją (prawdopodobnie niejawnie po wybraniu tej bazy danych podczas snu). – GDR

Odpowiedz

13

Więc nie jestem pewien, czy Matt Rogish's answer pomoże 100%.

Problemem jest to, że MySQL * ma muteksu (nie działa blokada) wokół tabelach otwierania i zamykania, dzięki czemu w praktyce oznacza, że ​​jeśli stół jest w procesie jest zamknięty/usunięty nie inne tabele mogą być otwarte .

ten został opisany przez mojego kolegi tutaj: http://www.mysqlperformanceblog.com/2009/06/16/slow-drop-table/

Jeden doskonała strategia redukcji oddziaływania jest użycie systemu plików XFS podobnego.

Sposób obejścia jest brzydki. Zasadniczo musisz skubać wszystkie dane w tabelach przed ich upuszczeniem (patrz komentarz nr 11 na powyższym linku).

+0

Wyjaśniłeś więc mechanizm blokujący i wszystko ma sens ... ale odpowiedź na pytanie "dlaczego" wciąż nie została wyjaśniona. Usunięcie wielu plików w systemie Linux nie trwa zbyt długo. Zgaduję, że pod maską dzieje się coś znacznie bardziej skomplikowanego. Jeśli tak, "dlaczego" robi to tak, jak przeciwstawia się po prostu usuwaniu swoich plików w kilka sekund i "bingo" ... wszystkie tabele spadły? – Jeach

+1

Jest jeszcze jeden powód oprócz powolnego usuwania fs - jeśli istnieje bardzo duża pula buforów, może nastąpić zamrożenie próbujące wyrzucić wszystkie strony należące do tabeli, która ma zostać usunięta. Zostało to poprawione w 5,5/5,6 za pomocą "leniwej" bezpłatnej metody. –

6

Domyślnie, wszystkie bazy danych innodb w danej instalacji serwera mysql używają tej samej fizycznej puli plików danych, więc możliwe jest, że "baza danych A" może wpłynąć na bazę danych B. Ponieważ "baza danych zrzutów" może wymagać dużego przeorganizowania Pliki danych innodb, jest możliwe, że jest to operacja blokowania, albo ze względu na intensywność operacji, albo według projektu.

Jednak myślę, że możesz sprawić, by każda baza danych używała różnych fizycznych plików, mimo że sam tego nie próbowałem, więc musisz sam określić szczegóły. W przeciwnym razie może być konieczne użycie dwóch różnych instalacji mysql obok siebie na tym samym komputerze, co jest doskonale wykonalne.

11

Po off skaffman:

zmienić my.cnf (i ponownie uruchomić MySQL) obejmuje:

innodb_file_per_table = 1 

(http://mysqldba.blogspot.com/2006/12/innodbfilepertable.html)

To da baz danych poświęconą przechowywania plików i podjąć to ze wspólnej puli. Pozwoli ci to robić fajne rzeczy, takie jak umieszczanie tabel/indeksów na różnych dyskach fizycznych, aby jeszcze bardziej dzielić I/O i poprawić wydajność.

Uwaga: to nie zmienia istniejących tabel; będziesz musiał wykonać pracę, aby uzyskać je w ich własnym pliku (http://capttofu.livejournal.com/11791.html).

+1

Myślę, że zawyżasz użyteczność użycia innodb_file_per_table = 1 do podziału I/O - RAID jest lepszym rozwiązaniem. Powód: Opcja Utwórz tabelę o nazwie DATA DIRECTORY nie jest obsługiwana przez InnoDB. Chcę przenieść oddzielną tabelę do innej partycji, muszę użyć dowiązania symbolicznego z powrotem do pierwotnej lokalizacji. Zaraz po uruchomieniu polecenia ALTER TABLE dowiązanie symboliczne zostanie zniszczone, a tabela zostanie przeniesiona z powrotem do pierwotnej lokalizacji. –

+0

Jestem zaskoczony, że ta pojedyncza opcja robi tak wielką różnicę. Jesteś ratownikiem! –