Оптимизация и восстановление базы данных сайта

Начну с того, что вчера я  попытался оптимизировать базу данных своего сайта с целью очистки его от накопившегося мусора и достижения максимальной скорости загрузки сайта.

Как водится у неопытных пользователе и тех, кто делает это в первый раз, в результате манипуляций с базой данных,  вначале я добился «расчудесного» результата  — потерял доступ в админпанели обоих моих блогов на вордпресс.

Но обо всем по порядку.

Для чего нужны ревизии и как их делать

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

Например, когда автор пишет статью (в текстовом редакторе WP, а не в Microsoft Word, например), в течении определенного времени, происходит ее автосохранениет каждые 60 секунд. То есть архивирование записей. Если статью писать долго, то таких архивов накапливается много и весь этот мусор от каждой статьи накапливается в базе данных. Использование плагинов типа WordPress Database Backup, имеющих функцию по оптимизации базы, все же не решает вопросы глубокой очистки базы данных. Что делать?

Как очистить и оптимизировать базу данных

Начнем с того, что неплохо было бы как-то  остановить   возникновение и накопление  архивов записей — ведь движок вордпресса так устроен, что постоянно делает ревизии записей во время написания документов. За пять часов написания статьи накапливается 300 ревизий. Для того, что бы «пресечь это дело»,  многие рекомендуют и поступают так: на сервере открывается файл «wp-config.php» и внего вставляют коды:

define (‘WP_POST_REVISIONS’, false);   —  запрещение ревизий;
define (‘EMPTY_TRASH_DAYS’, 0);   — очистка от мусора в течении определенного интервала времени (здесь вместо цифры можно поставить число 1, 2  — они указывают интервал в сутках, в течении которого будет производится очистка ревизий);

Некоторые предлагают более демократичный вариант с учетом подстраховки от потери содержания создаваемой записи( а вдруг свет вырубят!). Вот еще рекомендация: в  той же корневой папке нужно открыть другую папку– «wp-includes», а в ней отыскать файл – «default-constants.php». В этом файле нужно найти следующий код:

if ( !defined(‘WP_POST_REVISIONS’) )
define(‘WP_POST_REVISIONS’, true);

«true» можно заменить на «0»(ноль) или на «false»

Примечание: установленные коды, предполагают лишь дальнейшее отключение или уменьшение ревизий, но не устранение уже имеющихся. Что бы они исчезли, нужно обновить КАЖДУЮ статью. О том , как это сделать быстрее — читаем далее.
Варианты каждый выбирает для себя, однако эти рекомендации считаю вполне уместными для тех, кто желает видеть базу своего ресурса в надлежащем порядке постоянно.
В сущности, все что я рассказал выше, это лишь увертюра, самое главное — впереди: ведь теперь нужно шагать прямиком в святая святых — базу данных блога.
Будем чистить и оптимизировать: Хост — Управление базами MySQL — PhpMyAdmin — Войти — База данных — выбираем нужную базу( если их несколько) — кликаем SQL.
панель базы данных
Стоп!!! Прежде чем что-то с базой творить, сделайте резервную копию имеющейся базы. Для этого нажмите на строку  «Экспорт» и закачайте имеющуюся базу на жесткий диск компьютера.
После закачки файл будет в формате sql и выглядит он приблизительно так: Если вы что-то напортите в редактировании, базу можно будет легко восстановить, закачав этот файл непосредственно в PhpMyAdmin, использовав строку «Импорт».  Да,

восстановление базы решается таким простым путем и многие об этом не знают.

Но об восстановлении базы данных, чуть ниже.
А как же быть с ревизиями? Здесь тоже нужно использовать операции с кодами. Я не стану описывать подробно все возможности всех видов очистки, так как не нашел вразумительного ответа, как например правильно удалять спам-комментарии или что-то еще. Рекомендации есть, но звучат они как-то неубедительно и без уточнений. Но вот операция по ревизиям у меня удалась. Все просто — открываем  нужную базу, кликаем на строку SQL и в открывшееся окно вставляем код
DELETE FROM wp_posts WHERE post_type = «revision»
Если все нормально, придет утвердительный ответ от системы.
После оптимизации БД, желательно сделать ее резервную копию, снова выполнив операцию «Экспорт».

Восстановление базы данных

Собственно, я уже упомянул ранее о том, как это делать. Но далее я хочу сделать упор на то, что нужно, прежде чем восстанавливать БД,  нужно еще иметь ее архив, т.е. регулярно сохранять его в определенном месте и постоянно обновлять по мере изменений на вашем сайте. Для этого можно воспользоваться плагином WordPress Database Backup или ему подобными и установить правила архивации, промежуток времени архивирования и определить место хранения файлов: либо на компьютере, либо виртуальном сервере, либо на почте ( с последующей, при необходимости, закачкой на ЖД). Я предпочитаю хранить вновь поступающие файлы формата sql в специальной папке на почте.  Тем, кто не любит пользоваться плагином, придется оптимизировать и создавать резервные копии вручную, как это описывалось в статье выше — с использованием базы  MySQL. Рассказывать о том как установить и работать с плагинами для создания архивов БД здесь я считаю лишним: муссировать эту тему уж очень любят владельцы блогов с движком вордпресс и многие  считают  своим долгом обязательно раскрыть эту тему. Найти подобную информацию с достойными статьями очень просто.

На данном этапе можно было бы заканчивать статью, но я снова  вернусь к ее вступлению. Те, кто регулярно посещает мои блоги, наверняка заметит, что на нем нет предыдущей статьи. Заранее извиняюсь перед комментаторами, но восстановить, к сожалению, статью и комментарии, соответственно, я уже не смогу. Дело в том, что я как-то напартачил в базе данных,  так,что восстановления ее стало возможным только при  использовании последней резервной копии, созданной плагином, от 12 августа с.г. Я резервирую базу раз в неделю. База которую я сохранил «Экспортом» перед оптимизацией так почему-то  так и не восстановилась. Это остается для меня загадкой — но неприятным фактом и вы понимаете, что я испытал, пока ее восстановил!

Однако плохой опыт послужил хорошим уроком —  я научился восстанавливать БД(!) чем и делюсь с читателями. К сожалению информации о том  как и с помощью чего создавать резервные копии пишут многие ( кое-кто под копирку), а вот о том, как ее восстанавливать, очень мало. Я, например, нашел только одну статью, но указанный в ней метод, немного другой и  в очередной раз почувствовал, как  в критической ситуации включается мозг… (I)

Удивительным стал тот факт, что в восстановленном блоге,  после нескольких комментариев, пропали смайлики от плагина wp-Monalisa и переустановка его не дала нужных результатов (смайли отражаются только в текстовом формате); не удалось восстановить и другой плагин, которым пользовался раньше; потом решил вроспользоваться «безплагинным» методом(скрипт-код) — получилось криво. Но я все-таки нашел один очень интересный плагин для смайликов — очень он не похож на все мне известные и он удачно улегся на моем блоге. Но — об этом в следующей статье.

Всем успехов и не губите свои БД, друзья!
Черный Бог, белый Бог… Я центр своей идеальности.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *