После ошибочного UPDATE, DELETE или изменения схемы MariaDB можно вернуть к состоянию до операции с помощью PITR — восстановления на момент времени. Для этого нужны исправный бэкап, сделанный до ошибки, и непрерывная цепочка бинарных журналов от точки этой копии до выбранной границы.
Сначала собирают отдельную базу и проверяют результат на ней. Восстановление всей рабочей базы также уберёт корректные изменения после выбранной точки: если нужно вернуть только известные записи, используйте план выборочного восстановления.
1. Остановите причину ошибки и сохраните исходники
Отключите опасный импорт, скрипт или фоновую задачу. Зафиксируйте время и часовой пояс инцидента, затронутые таблицы, версию MariaDB и последние изменения схемы.
Сохраните текущее состояние базы, журналы приложения и доступные binlog в защищённое хранилище. Не очищайте журналы и не перезаписывайте единственный бэкап: они понадобятся для повторной попытки и сравнения.
2. Проверьте, достижима ли нужная точка
Составьте короткую опись:
- базовая копия завершилась успешно и относится к состоянию до ошибки;
- известны имя binlog и позиция, соответствующие именно этой копии;
- сохранены все следующие файлы журнала до инцидента в правильном порядке;
- доступны ключи расшифрования, если копия или журналы зашифрованы;
- подготовлены совместимые версии сервера и утилит восстановления.
У физической копии MariaDB Backup координаты находятся в файле mariadb_backup_binlog_info, а в старых выпусках — xtrabackup_binlog_info. Имя файла журнала и позиция работают вместе: одно число без имени не определяет точку. Это описано в процедуре PITR MariaDB.
Если binlog раньше не записывались или между копией и ошибкой потерян файл, обычный PITR через эту цепочку не доведёт базу до нужного состояния. Включение журналирования сейчас не восстановит прошлые события; проверьте архивы и другие пригодные копии.
3. Подготовьте изолированную базу
Разверните отдельный экземпляр без доступа посетителей и без автоматического подключения репликации. До запуска приложения отключите реальные платежи, рассылки, вебхуки и фоновые задания, включая события планировщика БД.
Физический бэкап сначала подготавливают через mariadb-backup --prepare совместимой версии, затем восстанавливают в пустой каталог остановленного отдельного сервера. Работайте с копией исходного комплекта; требования к версиям и каталогу приведены в инструкции MariaDB Backup.
SQL-дамп восстанавливается иначе. Для продолжения из binlog ему тоже нужны корректно зафиксированные координаты согласованного состояния: время создания файла дампа их не заменяет.
4. Найдите начало ошибочной транзакции
Сопоставьте время в приложении с событиями binlog. Утилита mariadb-binlog позволяет читать журнал; для разбора строковых событий используют --base64-output=DECODE-ROWS --verbose. Такой вывод предназначен для просмотра, а для воспроизведения нужен обычный вывод утилиты с исполняемыми событиями.
Не копируйте содержимое журнала в переписку: там могут оказаться данные клиентов. Анализируйте его в защищённой среде.
Почему одной отметки времени недостаточно
Параметр --stop-datetime прекращает чтение на первом событии с указанным или более поздним временем. Он использует локальный часовой пояс машины, где запущена утилита; события рядом по времени требуют проверки по содержимому.
Определите файл и позицию начала всей ошибочной транзакции, включая её служебные события. Остановка между её изменениями или непосредственно перед COMMIT не заменяет исключение транзакции целиком. Семантика параметров приведена в справочнике mariadb-binlog.
5. Воспроизведите проверенный диапазон
Начните с координат бэкапа и применяйте журналы по порядку до границы перед ошибочной транзакцией. Для числовых позиций --start-position относится к первому переданному файлу, а --stop-position — к последнему; список файлов должен соответствовать этим границам.
Не переносите команду из чужого примера без проверки своей версии и координат. При ошибке чтения или применения остановитесь и разберите её; повторное применение уже выполненного диапазона к той же базе способно исказить результат.
Для новой попытки вернитесь к чистому восстановлению базовой копии. Сохраните протокол: комплект бэкапа, список журналов, начальную и конечную позиции, версии утилит и итог применения.
6. Проверьте данные до переключения сайта
Убедитесь, что последняя ожидаемая корректная транзакция присутствует, а ошибочная отсутствует. Проверьте связи записей, статусы и суммы, а затем чтение данных через приложение; одного количества строк недостаточно.
Например, после ошибочного массового удаления заказы должны существовать в восстановленной копии вместе с позициями. При этом заказы, созданные позже выбранной точки, в неё не попадут: их судьбу нужно решить отдельно до замены рабочей базы.
Согласуйте допустимую потерю изменений, совместимость кода и файлов, окно остановки записей и план возврата. PITR базы не восстанавливает автоматически загруженные файлы и не отменяет уже выполненные внешние платежи.
После переключения Web-Puls может контролировать доступность публичной страницы или API. Это поможет заметить HTTP-сбой, но правильность восстановленных данных подтверждают прикладные проверки.
Если цепочка журналов неполна или граница транзакции неясна, отправьте заявку на профессиональную поддержку. Укажите публичный адрес сайта, время инцидента с часовым поясом, версию СУБД и наличие бэкапа; способ защищённой передачи материалов согласуйте отдельно, без дампов и паролей в форме.