WordPress «Базу даних потрібно відновити»: що це означає й як безпечно виправити

Що WordPress насправді каже

WordPress виводить «базу даних потрібно відновити», коли вважає, що одна або кілька таблиць пошкоджені або несумісні настільки, що звичайні запити
не виконуються. Непосередньою причиною зазвичай є помилка, повернена MySQL/MariaDB під час запуску або під час звичайного запиту: таблиця
позначена як зіпсована, відсутній індекс, пошкоджена сторінка, несподіваний кінець файлу (EOF) або невідповідність між тим, що очікує WordPress,
і тим, що він може прочитати.

Під капотом WordPress використовує невелику перевірку в шарі роботи з базою даних і, якщо бачить певні збої, пропонує потік відновлення
за допомогою вбудованого скрипта (wp-admin/maint/repair.php). Він може виконувати SQL-операції на кшталт REPAIR TABLE і
OPTIMIZE TABLE — що підходить для деяких движків зберігання і майже не має значення для інших.

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

Хороша фраза для інцидентів: «Сподівання — не стратегія.» — Vince Lombardi. Це різко, але доречно.

Швидкий план діагностики (перший/другий/третій)

Коли сайт недоступний, часу на розгляд руїн немає. Потрібно швидко визначити вузьке місце: стан движка БД, пошкодження на рівні таблиці чи
шар зберігання під ним.

Перший: підтвердьте, що це не просто проблема підключення або облікових даних

• Перевірте журнали вебсерверу на mysqli_real_connect помилки, помилки автентифікації, проблеми з DNS або Too many connections.
• Перевірте, що DB_NAME, DB_USER, DB_PASSWORD, DB_HOST в wp-config.php
  відповідають дійсності (їх не обертали без повідомлення WordPress).
• Спробуйте простий ping до БД з хоста WordPress. Якщо не вдається підключитися, «відновлення» навіть не запуститься.

Другий: подивіться журнали бази даних за фактичною скаргою

• Шукайтe повідомлення про відновлення після збою, попередження про корупцію InnoDB, «table is marked as crashed», невідповідність контрольної суми сторінки або «disk full».
• Якщо InnoDB застряг у циклі відновлення після збою, не перевантажуйте демона. Ви можете заглибити проблему.

Третій: встановіть, чи шар зберігання вам бреше

• Перевірте простір на диску та виснаження інодів. «Потрібно відновити» іноді означає «ми не змогли записати останню транзакцію».
• Перевірте журнали ядра на I/O помилки, перемонтування файлової системи або деградацію RAID, або події з хмарним томом.
• Якщо шар зберігання нестабільний, ремонт таблиць — це як фарбувати будинок під час пожежі.

Цікаві факти та контекст (те, що важливо)

1. Історично WordPress сильно підтримував MyISAM; сучасні інсталяції зазвичай працюють на InnoDB за замовчуванням у MySQL/MariaDB.
   Це важливо, бо «ремонт» — це поняття, орієнтоване на MyISAM.
2. Вбудований скрипт ремонту WordPress з’явився до ери, коли керовані хости зробили доступ до БД «чужою проблемою» — і він припускає, що ви
   можете запускати операції ремонту з рівня застосунку.
3. InnoDB використовує redo log і відновлення після збою; після втрати електроживлення він часто само-лікується без табличного ремонту, якщо диск цілий.
4. MyISAM таблиці можуть бути «позначені як зламані» після некоректного завершення роботи, бо в цього движка немає транзакційного відновлення після збою, як у InnoDB.
5. OPTIMIZE TABLE може блокувати таблиці на значний час залежно від движка та версії MySQL/MariaDB — «прості виправлення» можуть перетворитися на множник простою.
6. WordPress може виглядати зламаним через корупцію лише в одній таблиці: wp_options. Ця таблиця — гаряча точка для плагінів
   і часто перша, яка показує проблему.
7. Повідомлення про помилку іноді вводять в оману: запит, що падає з «incorrect string value» або «illegal mix of collations», може виглядати як «корупція»,
   але насправді бути невідповідністю charset/collation після оновлення або відновлення.
8. Попередження про «корупцію» InnoDB іноді походять від того, що шар зберігання повертає застарілі або неправильні дані (неправильно працюючий кеш,
   контролер або нестабільний віртуальний диск). Бази даних чудово виявляють брехню, але не завжди її виправляють.

Поширені причини та режими відмов

1) Некоректні завершення роботи та відновлення після збою

Втрата живлення, kernel panic, OOM kills, примусові рестарти платформою хостингу — бази даних не люблять сюрпризів. InnoDB спроєктовано для відновлення,
але саме відновлення потребує працездатного I/O на диску та достатнього вільного місця для журналів і тимчасової роботи. MyISAM більш крихкий; він може позначити
таблиці як зламані і вимагати явного ремонту.

2) Диск заповнений (або іноді іноди) що маскується під «корупцію»

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

3) Фактична корупція на диску

Ось справжня проблема: биті сектори, зламаний RAID, неправильно налаштоване мережеве блочне сховище або пошкодження файлової системи. InnoDB
повідомляє про невідповідності контрольних сум або «page corruption». У такому випадку «ремонт» з боку WordPress — здебільшого театральний.
Потрібні бекапи, тактика відновлення та іноді контрольований витяг даних.

4) Поведінка плагінів та надвеликий рядок

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

5) Операції «оптимізації», що пішли не за планом

OPTIMIZE TABLE, зміни схеми та масові видалення можуть спричинити величезний I/O, тимчасове використання диска й довгі блокування.
У спільних середовищах ви можете виснажити базу настільки, що WordPress розвалиться і скаже «потрібно відновити».

Жарт №1: «Базу даних потрібно відновити» — це спосіб WordPress сказати: «У мене все гаразд, але те, від чого я залежу, проходить загартування характеру.»

Практичні завдання: команди, очікуваний вивід і рішення

Нижче наведені практичні завдання, які можна виконати на типовому Linux-хості з MySQL/MariaDB і WordPress. Кожне завдання містить команди, приклад
виводу, що означає вивід, і наступне рішення. Копіюйте/вставляйте уважно; продакшн-системи чутливі до здогадок.

Завдання 1: Підтвердити, що WordPress може резолвити і дістатися хоста БД

cr0x@server:~$ getent hosts db.internal
10.20.30.40    db.internal

Що це означає: Дозвіл імен працює і у вас є IP.

Рішення: Якщо це не працює, виправте DNS/hosts/VPC маршрутизацію перед тим, як торкатися інструментів ремонту WordPress.

Завдання 2: Базова TCP-зв’язність до порту БД

cr0x@server:~$ nc -vz db.internal 3306
Connection to db.internal 3306 port [tcp/mysql] succeeded!

Що це означає: Мережевий шлях і security groups/firewall дозволяють підключення до БД.

Рішення: Якщо заблоковано, зупиніться. Ремонт таблиць не допоможе закритому порту.

Завдання 3: Перевірити облікові дані з wp-config.php

cr0x@server:~$ php -r 'require "wp-config.php"; echo DB_HOST, " ", DB_NAME, " ", DB_USER, PHP_EOL;'
db.internal wordpressdb wpuser

Що це означає: Ви витягли налаштовані цілі підключення.

Рішення: Якщо це не збігається з очікуваними значеннями (недавня ротація секретів, міграція БД), виправте конфіг перш ніж діяти далі.

Завдання 4: Спробувати простий вхід у MySQL і запит

cr0x@server:~$ mysql -h db.internal -u wpuser -p -e "SELECT 1;"
Enter password: 
1
1

Що це означає: Аутентифікація працює і сервер відповідає.

Рішення: Якщо ви отримуєте «Access denied», ремонт не має значення — виправте облікові дані/привілеї.

Завдання 5: Перевірити вільний простір та іноди на хості БД

cr0x@server:~$ df -h /var/lib/mysql
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  200G  198G  2.0G  99% /var/lib/mysql

Що це означає: Ви на відстані одного тимчасового таблиці від серйозної проблеми.

Рішення: Звільніть місце спочатку (логи, старі бекапи, binlogs) перед будь-яким ремонтом/оптимізацією.

cr0x@server:~$ df -i /var/lib/mysql
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/nvme0n1p3  13M     13M     2K   100% /var/lib/mysql

Що це означає: Вичерпання інодів може ламати записи навіть якщо «місця» на диску здається достатньо.

Рішення: Почистіть надмірні дрібні файли (tmp, логи). Якщо БД не може створювати файли, ремонти можуть падати посеред операції.

Завдання 6: Прочитати журнали MySQL/MariaDB для фактичної помилки

cr0x@server:~$ sudo tail -n 60 /var/log/mysql/error.log
2025-12-27T07:10:12.002345Z 0 [Warning] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=123, page number=456]
2025-12-27T07:10:12.002400Z 0 [ERROR] InnoDB: Page checksum mismatch on read.
2025-12-27T07:10:12.002430Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption

Що це означає: Це не «запустіть REPAIR TABLE». Це питання цілісності зберігання.

Рішення: Припиніть запис. Зробіть знімок/беккап. Плануйте відновлення/екстракцію з бекапів або контрольоване витягання даних.

Завдання 7: Перевірити, чи є MyISAM таблиці, позначені як зламані

cr0x@server:~$ mysql -h db.internal -u root -p -e "SELECT TABLE_SCHEMA,TABLE_NAME,ENGINE,TABLE_ROWS,CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_SCHEMA='wordpressdb' AND ENGINE='MyISAM';"
Enter password:
+-------------+-------------------+--------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME        | ENGINE | TABLE_ROWS | CREATE_OPTIONS |
+-------------+-------------------+--------+------------+----------------+
| wordpressdb  | wp_search_cache   | MyISAM |      12034 |                |
+-------------+-------------------+--------+------------+----------------+

Що це означає: У вас є принаймні одна MyISAM таблиця. Вони можуть потребувати REPAIR TABLE.

Рішення: Визначте, чи повідомлення про помилку конкретно посилається на ці таблиці. Якщо так — ремонтуйте їх після створення бекапу.

Завдання 8: Запустити перевірку таблиць, щоб знайти корупцію (швидко, з низьким ризиком)

cr0x@server:~$ mysqlcheck -h db.internal -u root -p --databases wordpressdb
Enter password:
wordpressdb.wp_posts                                 OK
wordpressdb.wp_options                               OK
wordpressdb.wp_search_cache                          error    : Table is marked as crashed and should be repaired
wordpressdb.wp_search_cache                          status   : Operation failed

Що це означає: Одна таблиця явно позначена як зламана.

Рішення: Ремонтуйте лише уражені таблиці. Не «оптимізуйте все» з нудьги.

Завдання 9: Зробити бекап перед ремонтом (логічний дамп)

cr0x@server:~$ mysqldump -h db.internal -u root -p --single-transaction --routines --triggers wordpressdb | gzip -1 > /tmp/wordpressdb.sql.gz
Enter password:

Що це означає: Ви зробили консистентний логічний бекап (best-effort; може впасти, якщо таблиці нечитаються).

Рішення: Якщо дамп падає на конкретній таблиці, зафіксуйте це. Розгляньте дамп таблиця за таблицею, щоб врятувати те, що можна.

Завдання 10: Ремонт MyISAM таблиці безпосередньо (цільовий)

cr0x@server:~$ mysql -h db.internal -u root -p -e "REPAIR TABLE wordpressdb.wp_search_cache;"
Enter password:
+------------------------------+--------+----------+----------+
| Table                        | Op     | Msg_type | Msg_text |
+------------------------------+--------+----------+----------+
| wordpressdb.wp_search_cache  | repair | status   | OK       |
+------------------------------+--------+----------+----------+

Що це означає: Ремонт таблиці пройшов успішно.

Рішення: Перезапустіть mysqlcheck. Якщо чисто, поверніть сайт в продакшн і моніторте журнали на повторення.

Завдання 11: Якщо WordPress доступний, використовуйте WP-CLI для перевірки/ремонту (безпечніше, ніж веб-сторінка)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp db check
Success: Database checked.
cr0x@server:~$ wp db repair
Success: Database repaired.

Що це означає: WP-CLI успішно виконав кроки обслуговування БД, які підтримує WordPress.

Рішення: Якщо WP-CLI падає з SQL-помилками, поверніться до журналів MySQL і цільових перевірок. Не намагайтеся бездумно повторювати спроби.

Завдання 12: Проінспектувати розміри найгірших таблиць (часто wp_options)

cr0x@server:~$ mysql -h db.internal -u root -p -e "SELECT table_name, ROUND((data_length+index_length)/1024/1024,1) AS mb FROM information_schema.TABLES WHERE table_schema='wordpressdb' ORDER BY (data_length+index_length) DESC LIMIT 10;"
Enter password:
+----------------+------+
| table_name     | mb   |
+----------------+------+
| wp_options     | 512.4|
| wp_posts       | 240.7|
| wp_postmeta    | 210.3|
| wp_actionscheduler_logs | 180.9|
+----------------+------+

Що це означає: Ваша options таблиця величезна, що часто корелює зі сповільненими запитами, таймаутами і симптомами «відновлення».

Рішення: Дослідіть автозавантажені опції та поведінку плагінів. Це ремедіація, а не ремонт.

Завдання 13: Визначити автозавантажувальний бакт у wp_options

cr0x@server:~$ mysql -h db.internal -u root -p wordpressdb -e "SELECT COUNT(*) AS autoloaded_rows, ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"
Enter password:
+----------------+-------------+
| autoloaded_rows| autoload_mb |
+----------------+-------------+
|          12456 |       88.40 |
+----------------+-------------+

Що це означає: WordPress завантажує автозавантажувані опції на багатьох запитах. 88 MB — це не «нормально». Це самоспровокований denial-of-service.

Рішення: Зменшіть автозавантажувані опції (налаштування плагінів, транзієнти) і додайте кешування. Не вважайте ремонт таблиць за вирішення проблеми.

Завдання 14: Перевірити довготривалі запити або очікування блокувань (спроби ремонту можуть погіршити це)

cr0x@server:~$ mysql -h db.internal -u root -p -e "SHOW FULL PROCESSLIST\G"
Enter password:
*************************** 1. row ***************************
     Id: 8123
   User: wpuser
   Host: 10.20.40.55:52111
     db: wordpressdb
Command: Query
   Time: 128
  State: Waiting for table metadata lock
   Info: OPTIMIZE TABLE wp_postmeta

Що це означає: Хтось запускає оптимізацію і блокує інших. Це може зробити WordPress «зламаним» на деякий час.

Рішення: Зупиніть/вбийте блокуючу операцію, якщо це доречно, потім плануйте обслуговування у вікно з чітким планом.

Завдання 15: Швидко перевірити стан движка InnoDB

cr0x@server:~$ mysql -h db.internal -u root -p -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,120p'
Enter password:
------------
TRANSACTIONS
------------
Trx id counter 987654321
Purge done for trx's n:o < 987650000 undo n:o < 0 state: running but idle
History list length 12

Що це означає: InnoDB працює і не має очевидних ознак застрягання з величезним history list або активним rollback.

Рішення: Якщо статус показує відновлення після збою, повторну корупцію або «waiting for» I/O, концентруйтеся на шарі зберігання і варіантах відновлення.

Завдання 16: Базові сигнали помилок зберігання (не пропускайте це)

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Sat Dec 27 07:08:10 2025] blk_update_request: I/O error, dev nvme0n1, sector 123456789
[Sat Dec 27 07:08:10 2025] EXT4-fs error (device nvme0n1p3): ext4_find_entry:1463: inode #262144: comm mysqld: reading directory lblock 0

Що це означає: Ваша база читає сміття, бо диск відмовляє або файлова система пошкоджена.

Рішення: Припиніть записи, зробіть знімок при можливості, мігруйте на здорове сховище і відновлюйте з бекапів. «Ремонт таблиць» не вирішить цього.

Безпечне використання WP_ALLOW_REPAIR (і не робити з нього відкритий бар)

WordPress містить вбудовану сторінку ремонту за адресою wp-admin/maint/repair.php. Вона вимкнена за замовчуванням і може бути увімкнена
шляхом додавання define('WP_ALLOW_REPAIR', true); у wp-config.php.

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

Безпечний порядок дій

• Віддавайте перевагу WP-CLI (wp db check / wp db repair), якщо маєте доступ до shell.
• Якщо мусите використовувати веб-сторінку ремонту, тимчасово увімкніть WP_ALLOW_REPAIR, виконайте ремонт, а потім одразу видаліть його.
• Обмежте доступ на рівні вебсерверу (allowlist IP) під час увімкнення.

Приклад: тимчасово увімкнути ремонт

cr0x@server:~$ sudo sed -i "s/^.*WP_ALLOW_REPAIR.*$/define('WP_ALLOW_REPAIR', true);/g" /var/www/html/wp-config.php

Що це означає: Ви ввімкнули режим ремонту (припускає, що рядок вже існував; будьте обережні з автоматичними правками).

Рішення: Негайно додайте IP-обмеження або поставте сайт за сторінку обслуговування, поки виконуєте ремонт.

Приклад: заблокувати endpoint ремонту для вашого IP (Nginx)

cr0x@server:~$ sudo nginx -T | sed -n '1,80p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Що це означає: Синтаксис конфігурації валідний перед перезавантаженням.

Рішення: Додайте location блок для /wp-admin/maint/repair.php і обмежте доступ, потім перезавантажте Nginx.

Жарт №2: Залишати WP_ALLOW_REPAIR ввімкненим — це як залишити машину з працюючим двигуном біля офісу — технічно зручно, соціально амбіційно.

InnoDB vs MyISAM: ремонти — зовсім різні речі

MyISAM: REPAIR TABLE — це реальність

Якщо уражена таблиця MyISAM, REPAIR TABLE може перебудувати індекси та виправити певні структурні проблеми. Воно все ще може впасти,
якщо файл даних сильно пошкоджений, але це легітимна перша відповідь після того, як ви зробили бекап того, що можете.

Корупція MyISAM зазвичай проявляється як «Table is marked as crashed» або «Can’t open file.» Ремонти можуть бути швидкими для малих таблиць і жорсткими для великих.
Також MyISAM використовує блокування на рівні таблиці; ремонти можуть блокувати читання/записи.

InnoDB: «ремонт» часто означає «відновлення»

Для InnoDB REPAIR TABLE не робить те, що багато хто очікує. InnoDB покладається на відновлення після збою, redo журнали і контрольні суми.
Коли InnoDB повідомляє про корупцію, ваш кращий «ремонт» зазвичай:

• Підтвердити стан зберігання (I/O помилки, стан файлової системи, події з хмарними томами).
• Відновити з відомо робочого бекапу/знімка, якщо він доступний.
• Якщо потрібно рятувати, використовувати контрольоване витягання: дамп того, що читається, ізоляція пошкоджених таблиць і відтворення з схеми + залишкових даних.

Не плутайте «оптимізацію» з «ремонтом»

Багато гайдів WordPress трактують OPTIMIZE TABLE як магічну мітлу. Насправді воно може:
блокувати таблиці, переписувати їх, вимагати величезного тимчасового простору і спричинити I/O стрибки, що виведуть на поверхню латентні проблеми з диском.
Це операція обслуговування, а не екстрена медицина.

Сторонні питання зберігання й хостингу (де часто починається корупція)

Як SRE, я навчився вважати застосунок кур’єром, а сховище — місцем злочину. Корупція бази даних часто є наслідком інфраструктурних подій, які ви не помітили:
«галасливий сусід», що насичує IOPS, перезавантаження ноди, перемонтування файлової системи у read-only або том, який тимчасово повертав помилки, а потім прикидався, ніби нічого не сталося.

Шукайте ці патерни зберігання

• Диск заповнений: легко підтвердити, легко виправити, дивно поширене.
• Файлова система лише для читання: раптові збої по всьому стеку; MySQL може зупинитися або відмовитися від записів.
• I/O помилки: показані в журналах ядра; журнали БД показують невідповідності контрольних сум; WordPress виводить «відновлення».
• Стрибки затримки: можуть маскуватися під корупцію, коли запити таймаутять або клієнти відключаються під час операцій.

Практичні перевірки стану зберігання (Linux)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
NAME         SIZE TYPE MOUNTPOINT     FSTYPE
nvme0n1      500G disk
└─nvme0n1p3  200G part /var/lib/mysql ext4

Що це означає: Підтверджує, який пристрій живить datadir MySQL.

Рішення: Якщо це мережевий том або епhemeral диск, відкоригуйте очікування і політику бекапів.

cr0x@server:~$ mount | grep /var/lib/mysql
/dev/nvme0n1p3 on /var/lib/mysql type ext4 (rw,relatime,errors=remount-ro)

Що це означає: Файлова система перемонтується в read-only при помилках (поширена налаштування за замовчуванням).

Рішення: Якщо ви бачите, що вона перемонтована в read-only, ви нічого не відремонтуєте, поки не виправите файлову систему/диск.

Три міні-історії з практики

Інцидент №1: Аутейж через хибне припущення

Середня компанія тримала WordPress для маркетингового сайту, який раптово почав показувати «базу даних потрібно відновити». Інженер на чергуванні побачив
повідомлення, згадав про endpoint ремонту WordPress, увімкнув WP_ALLOW_REPAIR, натиснув «Repair and Optimize» і чекав.

База стала повільнішою. Потім недоступною. Сайт, що був частково деградований, став повністю недоступним, і моніторинг почав кричати про помилки підключень.
Інженер припустив «вона ремонтується, дай їй час». Це припущення виявилося дорогим.

Корінь проблеми не був у корупції зовсім. Диск бази був на 99% заповнений. Крок оптимізації намагався перебудувати кілька великих таблиць,
створив тимчасові файли і отримав ENOSPC посеред операції. MySQL почав частіше падати з помилками, а WordPress, бажаючи допомогти, продовжував
радити ремонт.

Виправлення було нудним: звільнити місце, перезапустити MySQL чисто і знову виконати цільову перевірку. Їм не потрібна була оптимізація; потрібне
було управління ємністю. Після інциденту внесли ще більш нудну зміну: алерт при 85% заповнення диска і ранубук «звільнити місце перед ремонтом».
Не гламурно, але зупинило повторення інциденту.

Інцидент №2: Оптимізація, що зіграла злий жарт

Інша команда мала WordPress з роками зміни плагінів. Хтось помітив ріст бази і вирішив «почистити» її, запускаючи нічні оптимізації для всіх таблиць.
Це виглядало як відповідальність, як чистка зубів. Перші ночі минали без наслідків.

Потім трафік виріс і сайт почав кидати періодичні помилки в пікові години. Редактори скаржилися, що збереження чернеток інколи зависає.
Сервер показував високе I/O у незвичні години, а денна латентність погіршувалася. Люди звинувачували хостинг.

Проблема: задача оптимізації переписувала великі InnoDB таблиці щодня, створювала інтенсивний бекграунд I/O, збивала buffer pool і інколи блокувала метадані,
що колізувало з реальним трафіком. Тобто «обслуговування» конкурувало з продакшном, і продакшн програв.

Вони зупинили нічний optimize, провели цільову роботу: видалили плагін, що зберігав великі автозавантажувані боби, почистили транзієнти і додали нормальний object cache.
База зменшилась сама собою, бо перестали її годувати сміттям. Оптимізація не вирішила корінну причину; вона лише змусила систему працювати важче.

Інцидент №3: Нудна, але правильна практика, що врятувала день

Велике підприємство вело кілька WordPress властивостей. Нічого особливого — поки патч інфраструктури не викликав несподіване перезавантаження VM БД під час гарячого контент-пушу.
WordPress почав показувати підказки про ремонт, і кілька сторінок видавали помилки.

Команда не зачепила endpoint ремонту. Вони дотрималися runbook: заморозили запис (режим обслуговування), зробили знімок тому,
взяли свіжий логічний дамп і лише потім виконали перевірки. Це відчувалося повільно в моменті. Але це був правильний тип повільності.

Перевірки показали одну маленьку MyISAM legacy таблицю, позначену як зламана (залишок від давнього плагіна), і все інше було в порядку.
Вони відремонтували ту таблицю, валідовували сайт і повернулися в роботу. Знімок означав, що якби ремонт погіршив ситуацію, вони могли б миттєво відкотитися.

Тихий герой — практика, якою ніхто не хвалиться в статусах: завжди брати відновлювану точку перед тим, як «виправляти» щось. Це перетворило ризикову ситуацію
на контрольоване обслуговування і не дозволило інциденту вирости до масштабного відновлення.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: «Базу даних потрібно відновити» з’являється одразу після міграції

Корінь: Неповний імпорт, відсутні таблиці, неправильний префікс таблиць або невідповідність charset/collation, що призводить до збоїв запитів.

Виправлення: Перевірте префікс таблиць у wp-config.php, підтвердьте кількість таблиць і наявність базових таблиць, перевірте charset/collation бази. Імпортуйте чисто з дампа.

2) Симптом: Ремонт виконується, але повідомлення повертається через кілька годин

Корінь: Підлегле зберігання дає збої повторно, повторні некоректні завершення роботи або MyISAM таблиця постійно пошкоджується збоями.

Виправлення: Усуньте некоректні завершення роботи; перенесіть legacy MyISAM таблиці в InnoDB де можливо; перевірте журнали ядра/диску та події хостингу.

3) Симптом: Сторінка ремонту зависає або таймаутиться

Корінь: Великі таблиці, блокування метаданих або база перевантажена (I/O або CPU). Іноді PHP max execution time перериває процес.

Виправлення: Віддавайте перевагу CLI-інструментам (mysqlcheck, WP-CLI). Ремонтуйте по одній таблиці. Плануйте важкі операції поза піками.

4) Симптом: «Error establishing a database connection» плюс плутанина з повідомленням про ремонт

Корінь: Ліміти підключень, БД не працює, DNS/мережа або невідповідні облікові дані. Не корупція.

Виправлення: Виправте підключення й облікові дані. Перевірте max_connections і поведінку пулінгу підключень застосунку.

5) Симптом: MySQL перезавантажується повторно після попередження про ремонт

Корінь: Відновлення InnoDB не вдається через корупцію, заповнений диск або помилки файлової системи.

Виправлення: Припиніть трешинг. Збережіть стан. Перегляньте журнали помилок і стан диска. Відновіть з бекапу/знімка або проведіть контрольоване витягнення даних.

6) Симптом: Адмін панель завантажується, а фронтенд видає випадкові 500 і повідомлення про ремонт

Корінь: Автозавантажувальне наповнення, таблиці плагінів, що розростаються, повільні запити, таймаути або конфлікт блокувань.

Виправлення: Визначте найбільші таблиці, дослідіть автозавантажувані опції, оберніть/ротаціюйте таблиці логів, додайте кешування і налаштуйте індекси там, де потрібно.

7) Симптом: Ви виправили одного разу і тепер стало гірше

Корінь: Ви запускали optimize/repair на диску з відмовами або без вільного простору, зробивши часткові переписи і загостривши пошкодження.

Виправлення: Відновіть до знімка/бекапа перед ремонтом, стабілізуйте зберігання й ємність, потім повторіть цільові ремонти з планом відкотування.

Контрольні списки / покроковий план

Аварійний план (сайт деградований або недоступний)

1. Стабілізувати: переведіть WordPress у режим технічного обслуговування або інакше зменште записи (відключіть cron, призупиніть важкі задачі).
2. Підтвердити зв’язок: перевірте досяжність хоста БД і правильність облікових даних.
3. Перевірити ємність: підтвердьте простір диска та іноди на хості БД; звільніть місце, якщо потрібно.
4. Прочитати журнали БД: визначте, чи це MyISAM crash, відновлення InnoDB або I/O помилки диска.
5. Зробити відновлювану копію: зробіть знімок тому, якщо доступно; потім спробуйте mysqldump.
6. Знайти уражені таблиці: запустіть mysqlcheck або цільовий CHECK TABLE.
7. Ремонтуйте лише пошкоджене: використовуйте REPAIR TABLE для MyISAM; уникайте широких optimize-операцій.
8. Валідовати: повторно запустіть перевірки; проганяйте основні сторінки; слідкуйте за журналами помилок.
9. Прибрати експозицію ремонту: якщо ви ввімкнули WP_ALLOW_REPAIR, відразу видаліть його.
10. Моніторинг: спостерігайте за I/O диска, журналом помилок MySQL та помилками WordPress протягом 24–48 годин.

План стабільності (після відновлення)

1. Перевести legacy таблиці: мігруйте MyISAM таблиці в InnoDB, де можливо.
2. Виправити гігієну даних плагінів: зменшіть автозавантажувальні опції, ротуйте таблиці логів, видаліть занедбані плагіни.
3. Реалізувати бекапи, які можна відновити: і знімки, і логічні дампи, тестувати регулярно.
4. Додати запобіжники: алерти по дисковому простору, логування повільних запитів і політику вікон для перезапису таблиць.
5. Репетиція відновлення: проведіть відновлення з бекапу. Одного разу. Ви будете спати краще.

Питання й відповіді

Чи завжди «базу даних потрібно відновити» означає корупцію?

Ні. Це означає, що WordPress зіткнувся з помилками бази, що узгоджуються з пошкодженими таблицями або несумісними метаданими. Заповнений диск, конфлікти блокувань,
таймаути і проблеми з обліковими даними можуть імітувати симптоми «потрібно відновити».

Чи безпечно натискати «Repair Database» у WordPress?

Іноді. Досить безпечно для проблем з MyISAM і незначних невідповідностей. Це не заміна бекапів і не виправить проблеми з шаром зберігання.
Якщо можете — зробіть знімок/дамп перед цим.

Чи варто запускати «Repair and Optimize»?

У екстрених випадках зазвичай ні. Optimize може бути важким, блокувальним і ємкісно витратним. Ремонтуйте конкретні пошкоджені таблиці спочатку; оптимізуйте пізніше
у вікні з достатнім вільним місцем і планом відкату.

Чому це повторюється після ремонту?

Повторні ремонти зазвичай вказують на повторювані некоректні завершення роботи, диск на межі відмови або крихкий MyISAM, що досі використовується.
Інша поширена причина — плагін, який генерує надмірні записи й «ламає» систему під навантаженням.

Чи WP-CLI може це виправити без увімкнення WP_ALLOW_REPAIR?

Так. wp db check і wp db repair WP-CLI реалізують ті самі ідеї, але через CLI, що зазвичай безпечніше, ніж відкриття веб-ендпойнта.

Що робити, якщо база даних взагалі не стартує?

Тоді WordPress нічого не відремонтує. Йдіть на рівень бази: перевірте простір диска, стан файлової системи і журнали помилок MySQL. Якщо InnoDB повідомляє про
постійну корупцію, відновлюйтесь з бекапів/знімків або робіть контрольоване витягання даних.

Чи запобіжить конвертація таблиць в InnoDB цим проблемам?

Вона зменшує один клас проблем (MyISAM таблиці, позначені як зламані), оскільки InnoDB має відновлення після збою. Але це не захистить від корупції диска,
заповнення диска, поганих міграцій або шкідливої поведінки плагінів.

Чи можна ремонтувати через phpMyAdmin?

Можна, але це не мій перший вибір. Веб-інструменти зручні, але часто таймаутять посеред операції. Для перевірок і ремонтів CLI-інструменти (mysqlcheck, mysql, WP-CLI)
дають кращий контроль і легше аудиту.

Який бекап найнадійніший перед ремонтом?

Найкраще — знімок сховища тома (швидкий відкат) плюс логічний дамп (mysqldump --single-transaction) для портативності. Якщо підозрюєте корупцію,
очікуйте, що дампи можуть падати на окремих таблицях — рятуйте те, що можна.

Чи потрібно вимикати WordPress cron під час ремонту?

Якщо сайт нестабільний — так. Cron і фонові задачі можуть продовжувати записувати під час стабілізації, ускладнюючи відновлення.
Припиніть фонові процеси, відремонтуйте базу, а потім знову увімкніть роботу у фоні.

Наступні кроки, які варто виконати

Коли WordPress каже «базу даних потрібно відновити», не розглядайте це як підказку з UI. Розглядайте це як сигнал, що шар даних повертає помилки, і ваше завдання —
визначити класи: підключення, ємність, відновлення движка або реальна корупція.

Ваші практичні наступні кроки:

1. Пройти швидкий план діагностики: підключення → журнали БД → стан зберігання.
2. Зробити бекап (знімок + дамп) перед будь-яким ремонтом.
3. Використати mysqlcheck або WP-CLI, щоб знайти конкретні проблемні таблиці.
4. Ремонтуйте лише те, що зламане; уникайте «оптимізувати все» під час інциденту.
5. Після відновлення виправте корінь: місце на диску, гігієна даних плагінів, шаблони збою та протестовані бекапи.

Якщо все зробити правильно, повідомлення про «ремонт» стане коротким технічним обслуговуванням, а не хобі на вихідні.