может mysqldump в большой базе данных вызывать зависание моих длинных запросов? - PullRequest
0 голосов
/ 14 марта 2012

У меня большая база данных (около 50 ГБ). Он находится на сервере, над которым у меня мало контроля, но я знаю, что они используют mysqldump для резервного копирования по ночам.

У меня есть запрос, который занимает несколько часов. Я настроил его на запуск, но на самом деле он никогда не заканчивается.

Я заметил, что после времени резервного копирования все таблицы имеют запрос на блокировку (ПОКАЗАТЬ ОТКРЫТЫЕ ТАБЛИЦЫ ГДЕ in_use> 0; перечисляет все таблицы).

В таблицах из моего запроса in_use = 2, во всех других таблицах in_use = 1.

Итак ... что здесь происходит? а) мой запрос работает нормально, блокируя дамп. Я должен просто подождать? б) дамп вызывает зависание сервера (может быть, нехватка памяти / дискового пространства?) в) что-то еще?

РЕДАКТИРОВАТЬ: используя таблицы MyISAM

Есть администратор сервера, который не очень компетентен, но если я спрашиваю его о конкретных вещах, он делает их. Что я должен заставить его проверить?

РЕДАКТИРОВАТЬ: добавление запроса

SELECT citing.article_id as citing, citing.year, r.id_when_cited, cited_issue.country
FROM isi_lac_authored_articles as citing # 1M records
        JOIN isi_citation_references r ON (citing.article_id = r.article_id) # 400M records
        JOIN isi_articles cited ON (cited.id_when_cited = r.id_when_cited) # 25M records
        JOIN isi_issues cited_issue ON (cited.issue_id = cited_issue.issue_id) # 1M records

Это то, что EXPLAIN говорит:

+----+-------------+-------------+------+--------------------------------------------------------------------------+---------------------------------------+---------+-------------------------------+---------+-------------+
| id | select_type | table       | type | possible_keys                                                            | key                                   | key_len | ref                           | rows    | Extra       |
+----+-------------+-------------+------+--------------------------------------------------------------------------+---------------------------------------+---------+-------------------------------+---------+-------------+
|  1 | SIMPLE      | cited_issue | ALL  | NULL                                                                     | NULL                                  | NULL    | NULL                          | 1156856 |             |
|  1 | SIMPLE      | cited       | ref  | isi_articles_id_when_cited,isi_articles_issue_id                         | isi_articles_issue_id                 | 49      | func                          |      19 | Using where |
|  1 | SIMPLE      | r           | ref  | isi_citation_references_article_id,isi_citation_references_id_when_cited | isi_citation_references_id_when_cited | 17      | mimir_dev.cited.id_when_cited |       4 | Using where |
|  1 | SIMPLE      | citing      | ref  | isi_lac_authored_articles_article_id                                     | isi_lac_authored_articles_article_id  | 16      | mimir_dev.r.article_id        |       1 |             |
+----+-------------+-------------+------+--------------------------------------------------------------------------+---------------------------------------+---------+-------------------------------+---------+-------------+

Я на самом деле не понимаю, почему нужно просматривать все записи в таблице isi_issues. Разве это не должно совпадать с isi_articles (процитировано) в issue_id? Оба поля проиндексированы.

Ответы [ 2 ]

2 голосов
/ 14 марта 2012

Для базы данных MySQL такого размера вы можете рассмотреть вопрос о настройке репликации на подчиненный узел, а затем выполнять ночное резервное копирование базы данных на подчиненном.

1 голос
/ 14 марта 2012

Да - некоторые параметры mysqldump будут блокировать все таблицы MyISAM во время резервного копирования, чтобы резервное копирование представляло собой согласованный «моментальный снимок» момента времени.

InnoDB поддерживает транзакции, что делает это ненужным. Это также обычно быстрее, чем MyISAM. Вы должны использовать это. :)

...