Суть в том, что мы не прерываем выполнение запросов на чтение, но в то же время получаем консистентный бэкап.
Делаем:
В mysql-консоли:
Ждем пока выполнится запрос.
В другой консоли просто копируем папку с нужной базой (базами) в бэкап.
В mysql-консоли:
Ставим апач:
Конфиги в /etc/apache2/
Для добавления виртуалхоста создаем его конфиг (domain.com) в /etc/apache2/sites-available/ и:
Для выключения:
Для включения модулей апача:
Ставим мускул:
Конфиги в /etc/mysql/
Ставим nginx:
Проверка и восстановление всех баз:
Оптимизация всех таблиц всех баз:
Скрипт читает построчно из файла и создает базы с таким именем и юзером. Пароли к ним генерит.
Внимание к длине имени базы! (не больше 16 символов)
Проблема проявляется при апдейте (yum –enablerepo=remi update mysql) мускула с уже существующими таблицами. Выглядит она как сообщение: “cannot proceed because system tables used by Event Sheduler were found damaged at server start” при попытке сбэкапить базу.
Для починки:
При переносе базы с одного сервера на другой посмотреть в какой кодировке создана база (show create database base_name) и таблица (show create table table_name). Так же необходимо знать в какой кодировке были сами данные.
сделать дамп:
если заливать надо будет на MySQL 4 то так:
где latin1 – кодировка самих таблиц исходной базы, а не данных! Тогда при создании дампа данные не будут перекодироваться и отдадуться в правильном виде.
Далее надо открыть дамп в редакторе поддерживащем UTF8, например, в Notepad++ и проверить, что данные нормально читаются. Потом отредактировать этот дамп и поменять в операторах создания базы и таблиц latin1=>utf8. Потом уже заливать в новое место как UTF8.
ЗЫ. Если после всех этих телодвижений wordpress показывает кракозябры – надо прописать define(‘DB_CHARSET’, ‘utf8′); в wp-config.php
базы будем держать в /home/mysql
копируем my.cnf
Конфига мускула зависят от размера базы, размера оперативы, характера нагрузки и тд.
Но для сервака порядка Xeon 5150 / 2GB и средней нагрузки можно для начала так:
Для выявление тормозных запросов можно использовать slow log, mytop.
Посмотреть эффективность кэширование:
Qcache_free_blocks показывает сколько свободных блоков есть в кеше;
Qcache_total_blocks – количество занятых блоков;
Qcache_free_memory говорит о том, сколько свободной памяти осталось в кеше;
Qcache_hits – количество запросов, результаты которых были взяты из кеша;
Qcache_inserts – количество запросов, которые были добавлены в кеш;
Qcache_lowmem_prunes – количество запросов, которые были удалены из кеша из-за нехватки памяти;
Qcache_not_cached – количество запросов, которые не были записаны в кеш из-за использования функций работы со временем и т.п.;
Qcache_queries_in_cache – количество запросов, которые находятся в кеше.
После начала эксплуатации еще хорошо посмотреть что о настройках скажет
Оптимизация таблиц:
Важный момент (FreeBSD):
Необходимо следить, чтобы размер процесса mysqld не превысил максимального размера памяти доступного для одного процесса. Если используется FreeBSD c архитектурой i386, то по умолчанию этот размер равен 512MB. Если произойдет превышение, то в логе мускуля будут такие сообщения: “/usr/local/libexec/mysqld: Out of memory (Needed 2375270 bytes)”. Чтобы увеличить это значение необходимо сделать kern.maxdsiz=1073741824 в /boot/loader.conf
Посчитать объем памяти, который займет mysqld можно по этой формуле: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
