У меня на одном из проектов есть большая MySQL база.
Большая, это около 1 Тб ( 950 Гб ) и она растет.
Периодически, несколько раз в год, это чудо сыпется. Причины бывают разные, чаще всего это связано с рейдом (raid 1) - вылетают винты, а после синхронизации умирают таблицы индексов. И соответственно приходится все это дело восстанавливать, что доставляет массу неудобств.
База состоит всего из 7 таблиц формата MyISAM. Основные данные находятся в одной таблице (~ 850 Гб).
От InnoDB отказались сразу же после первой попытки восстановления 300 Гб базы, это был кошмар.
Есть возможность изменить способ хранения таким образом, чтобы данную таблицу разбить по англ алфавиту, т.е. вместо 1 таблицы 850 Гб, получится 850 / 26 ~ 32 Гб
Это несомненно увеличит скорость восстановления в случае проблем, а так же даст возможность работать с частями базы, независимо от других частей (тут я имею ввиду, что если восстановили таблицы: "A", "B", "C", то их можно вернуть в работу).
Посещаемость (вместе с ПС) колеблется от 150к до 1кк в день, к базе попадает, около 25-50 запросов в секунду.
Вопросы:
- Какие есть подводные камни, в таком делении базы (32 табл вместо 1)?
- Каким еще образом можно делить большие базы?
- Есть ли способы избежать разделения, кроме репликации и изменения способа хранения, в частности рейда?
P.S. Если есть литература, на эту тему (хранение и управление "большими" объемами данных), прошу помочь с названиями.
Не знал о такой возможности, буду тестировать и рассматривать.
Возможно, у Вас уже есть опыт использования партицирования и сможете подсказать, что будет, если один из файлов партиционированной таблицы посыпется? Как я понимаю, все запросы к данной таблице до восстановления посыпавшегося файла перестанут работать, до полного восстановления таблицы ( тут, написано что " [при] SELECT, INSERT, UPDATE MySQL произведет следующие манипуляции: откроет все партиции всех таблиц участвующих в запросе..". Это значит что при выходе из строя 1го файла таблицы, например файл буквы "A", таблица не может быть открыта, хотя запрос будет использовать только файл на букву "Z"). Так ли это?
Если так, то это не даст преимуществ, перед распределением данных по разным таблицам, где за каждую будет отвечать отдельный независимый файл, и в случае проблем, я быстро смогу идентифицировать проблему. Так же возникает вопрос, как найти именно плохой файл среди файлов "партиций", чтобы сразу начать восстанавливать именно его?
Пума Тайланд: у меня несколько раз в год сыпется файл индексов самой большой таблицы. Чаще всего это связано с такой ситуацией: вылетает один из винтов в рейде (или готовится к смерти), пул запросов к бд переполняется, т.к. база не может работать. После этого все запросы убиваются через kill, и mysql завершается с помощью service mysql stop. После замены hdd и синхронизации винтов, у таблиц появляется статус "используется" ("in use"), помогает только: myisamchk с увеличенными буферами, но на таблице в 850 Гб, никакие буфера не помогут, все очень медленно..
Т.е., да, проблема изначально не в MySQL, а в том, что при стечении обстоятельств файлы портятся, и в моем случае, к сожалению, это происходит довольно часто.
Даже если рассмотреть проблему, с упавшим сервером. Предположим что посыпались файлы используемых при падении таблиц, то правильно ли я понимаю, что при использовании партицированния, вся таблица перестанет работать, в независимости от кол-ва испорченых файлов? В случае использования отдельных таблиц, мне кажется, вероятность вылета уменьшится и при этом их можно будет быстрее вводить в строй.
М.б., Вам на вскидку приходят в голову, какие-то другие проблемы разделения данных?
Vitaliy Orlov: как то вы выбрали не правильный уровень рейда и сами страдаете от этого, при партицировании проблема особо не стоит, ну отвалилась партиция одна, ну взяли починили
Простой
Простой
