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