додаток a

Перед офіційним випуском всі версії MySQL тестуються на багатьох платформах. Це не означає, що в MySQL зовсім немає помилок, але якщо вони і є, то мало, і їх не так просто відшукати. У будь-якому випадку, зіткнувшись з якоюсь проблемою, завжди корисно спробувати точно визначити, що викликає аварію системи, - тоді шанси, що проблема буде усунена незабаром, стануть значно вище.

Спочатку треба спробувати локалізувати проблему. Визначте, що відбувається: чи то демон mysqld припиняє роботу, то чи проблема пов'язана з клієнтом. Дізнатися, скільки часу сервер mysqld вже працює, можна, виконавши mysqladmin version. Якщо mysqld припинив виконання, то для з'ясування причин можна вивчити файл mysql-data-directory / `hostname`.err (see Розділ 4.9.1,« Журнал помилок »).

Причиною багатьох аварій MySQL є пошкоджені індексні файли або файли даних. MySQL оновлює дані на диску, використовуючи системний виклик write (). після кожної команди SQL і до того, як клієнт буде повідомлений про результат (проте при виконанні з delay_key_write це не так: записуються тільки дані). Звідси випливає, що дані не постраждають навіть в разі аварійного завершення mysqld. оскільки ОС подбає про те, щоб ті дані, що не скинуті, були записані на диск. Можна змусити MySQL скидати все на диск після кожної SQL-команди, запустивши mysqld з --flush.

Все це означає, що зазвичай таблиці не повинні пошкоджуватися; виняток становлять такі випадки:

Хто-небудь / що-небудь вб'є процес mysqld або вимкне машину посеред операції оновлення.

Проявила себе помилка в mysqld. що викликає припинення його виконання посеред операції оновлення.

Хто-небудь працює з файлами даних або індексними файлами поза mysqld і при цьому не робить блокування таблиць як слід.

Якщо працює кілька серверів mysqld з одними даними на системі без пристойної підтримки блокувань файлової системи (зазвичай реалізується демоном lockd) або якщо виконується кілька серверів зі --skip-external-locking

Існує пошкоджений індексний файл або файл даних, що містить дуже неправильні дані, які вводять в оману mysqld.

Проявила себе в коді записи даних. Це малоймовірно, але в загальному випадку можливо. В цьому випадку можна спробувати змінити формат файлу на відповідний іншому оброблювачу баз даних, використовуючи ALTER TABLE на виправленої копії таблиці!

Оскільки знайти причину збою завжди непросто, спочатку можна спробувати з'ясувати, що з того, що працює у інших, викликає аварії у вас. Спробуйте виконати наступні дії:

Зупиніть демон mysqld за допомогою mysqladmin shutdown. виконайте myisamchk --silent --force * / *. MYI на всіх таблицях і перезапустіть демон mysqld. Цим гарантується безпомилковість вихідного стану (see Глава 4, Адміністрування баз даних).

Використовуйте mysqld --log і спробуйте визначити за інформацією в журналах, чи не викликано припинення роботи сервера будь-якою специфічною запитом. Близько 95% всіх помилок обумовлені конкретними запитами! Зазвичай це один з останніх запитів в журнальному файлі безпосередньо до перезапуску MySQL (see Розділ 4.9.2, «Загальний журнал запитів»). Якщо ви зумієте повторно викликати відмову MySQL за допомогою одного із запитів, навіть коли таблиці були перевірені безпосередньо перед виконанням запиту, то можлива локалізація помилки і підготовка звіту про помилку! see Розділ 1.8.1.3, «Як відправляти звіти про помилки або проблеми».

Спробуйте зробити контрольний тест, який ми могли б використовувати, щоб відтворити проблему (see Розділ E.1.6, «Створення контрольного прикладу при пошкодженні таблиць»).

Спробуйте виконати входить в поставку тест mysql-test і тести продуктивності MySQL (see Розділ 9.1.2, «Пакет тестування MySQL»). Ці тести повинні досить добре протестувати MySQL. Ви можете також додати в тести продуктивності код для імітації свого застосування! Тести продуктивності можна знайти в каталозі bench в постачанні з вихідними кодами або, в разі бінарної поставки, в підкаталозі sql-bench свого каталогу інсталяції MySQL.

Спробуйте fork_test.pl і fork2_test.pl.

Якщо щось піде не так, то збирати інформацію про можливі помилки буде значно простіше, якщо MySQL налаштований для налагодження. Переконфигурирует MySQL, застосовуючи configure з опцією --with-debug або --with-debug = full. і потім Перекомпілюйте (see Розділ E.1, «Налагодження сервера MySQL»).

Конфігурація MySQL в отладочном режимі призводить до включення безпечного розподільника пам'яті, який може знаходити деякі помилки. Крім цього, отладочная версія видає велику кількість інформації про те, що відбувається.

З'ясуйте, застосовані чи останні патчі для операційної системи.

Використовуйте опцію --skip-external-locking до mysqld. На деяких системах менеджер блокувань lockd не працює як слід; опція --skip-external-locking вказує mysqld не застосовувати зовнішню блокування (це означає, що не можна виконувати два сервера mysqld на одних даних і що необхідно бути обережним при використанні myisamchk. однак застосування цієї опції може принести велику користь для цілей тестування).

Якщо виникне ситуація, коли здається, що mysqld запущений, але не відповідає, варто спробувати виконати mysqladmin -u root processlist. Іноді mysqld не є завислим, навіть якщо здається, що це так. Проблема може бути в тому, що всі з'єднання використовуються, або, можливо, є якась внутрішня проблема з блокуваннями. mysqladmin processlist зазвичай здатна встановити з'єднання навіть в таких випадках і видати корисну інформацію про поточну кількість з'єднань і їх стані.

Виконайте команду в окремому вікні mysqladmin -i 5 status або mysqladmin -i 5 -r для виведення статистики, поки будуть виконуватися інші запити.

Спробуйте виконати наступні дії:

Запустіть тестові скрипти.

Відкрийте стек (backtrace) і локальні змінні на трьох нижніх рівнях. У gdb це можна зробити наступними командами після аварійного завершення mysqld всередині gdb:

За допомогою gdb можна також з'ясувати, які є потоки (за допомогою info threads), і переключитися на певний потік за допомогою thread #. де # - номер потоку.

Спробуйте імітувати роботу свого застосування за допомогою Perl-скрипта, який би викликав крах або неправильне функціонування MySQL.

Надішліть нам звичайний звіт про помилку (see Розділ 1.8.1.3, «Як відправляти звіти про помилки або проблеми»). Будь-які подробиці будуть не зайвими. Оскільки MySQL нормально експлуатується в дуже багатьох місцях, то, можливо, аварія викликана причиною, яка властива тільки вашого комп'ютера (наприклад, помилка, пов'язана з вашими особливими системними бібліотеками).

Якщо виникла проблема з таблицями, що мають динамічну довжину рядків, і не використовуються стовпці типу BLOB / TEXT (а тільки стовпці типу VARCHAR), то можна спробувати змінити все VARCHAR на CHAR за допомогою ALTER TABLE. Це змусить MySQL використовувати рядки фіксованого розміру. Для рядків фіксованого розміру знадобиться трохи додаткової пам'яті, проте вони набагато менш чутливі до пошкоджень! Сьогоднішній код динамічних рядків без яких би то не було проблем експлуатується в MySQL AB принаймні 3 роки, але в принципі рядки динамічної довжини більш схильні до помилок, тому даний рецепт, можливо, зможе вам чимось допомогти!