И именно поэтому необходимо дать доступ нескольким доверенным IP адресам, занеся их в белый список доверенных IP. В моем случае я дал доступ паре терминальных серверов, к которым имею доступ, двум купленным прокси серверам, а также к консоли еще пары серваков, которые удаленно администрирую по ssh. Ибо если у вас нет доступного терминального сервера, или же вы не можете использовать доверенный прокси сервер, то можно дать доступ хотя бы на какой нибудь собственный VPS с которого и можно разблокировать доступ к Cpanel WHM используя командную строку, путем обнуления базы брута.

Делается это следующим образом. Заходим в консоль, а дальше залезаем в командную строку мускуля:
# mysql
mysql> use cphulkd;
mysql>BACKUP TABLE `brutes` TO ‘/path/to/backup_file’;
Смотрим что вообще у нас есть в базе бана брута
mysql> SELECT * FROM `brutes`;
После этого, если список большой, то выбираем из базы свой IP и удаляем его
mysql> SELECT * FROM `brutes` WHERE `IP`=’X.X.X.X’;
mysql> DELETE FROM `brutes` WHERE `IP`=’X.X.X.X’;
mysql>\q

Узнать свой IP можно либо трейсом, либо зайдя на рутер либо воспользовавшись любым из многочисленных сервисов, определяющих IP адрес- ну хотя бы этот: WhatIsMyIP

Взять то я его взял, но вебмастера не могли ничего делать, так как на любую операцию система ругалась:
ERROR 1135 (HY000): Can’t create a new thread (errno 11); if you are not out of available memory
gzip: error while loading shared libraries: cannot create cache for search path: Cannot allocate memory
подключившись, я обнаружил что при попытке логина по ssh вылетала ошибка:
bash: fork: Cannot allocate memory

То бишь сделать ничего мог, так что отписался суппорту, что вот есть проблема с серваком. так что решите плиз. Суппорт же начал меня грузить на предмет того, что мне надо с апгрейтиться до 1Gb чтобы у меня все стало отлично, так как ось и Direct Admin отжирают все 512Mb. Я же давил на то, что top, к которому я таке смог пробиться показывает что занято всего 42% памяти и значит парни не тока оверселят, но еще и оверлодят память.

В таком духе мы препирались часов 5, поскольку мне некогда было лезть и особо разбираться. Я пару раз обложил в сердцах суппорт матюгами, после чего они начинали шевелиться быстрее, но все равно начинали втулять мне необходимость покупки 1Gb. Хотя по началу я хотел забрать бабло, накатать абузу в палку, в итоге во втором часу решил все таки глянуть более предметно, что происходит. Кстати в этом ключе- суппорт вещь такая- буквально в парралель  меня упал мой VPS и если честно я решил что это месть Burst, но оказалось что там была проблема с диском и другой чувак мне все замечательно и быстро решил, тем более что я конечно нервничал, так как буквально на этой неделе запилил два симпотных сайта, а бэкап датировался естественно началом сентября.

Ну вообщем сунулся кое как в сервак и понял, что мускуль кушает под себя 360Mb, так как грузится без файла конфигурации. Уж не знаю- толи забыли создать при первоначальной настройке, толи удалили в сердцах вебмастера, но пришлось озадачиться тюнингом MySQL под сервер с 512M, поместив в файл /etc/my.cnf следующие строки:
[mysqld]
local-infile=0
socket = /var/lib/mysql/mysql.sock
max_connections=300
slow-query-log
query_cache_limit=16M
query_cache_size=32M
key_buffer=16M
sort_buffer=64M
read_buffer = 2M
read_rnd_buffer_size = 768k
read_buffer_size=64M
max_allowed_packet=16M
thread_stack = 128K
skip-innodb
table_cache = 64M
Поскольку у меня оказалась InnoDB (правда не совсем понятно с какой целью мне ее прикрутили, хотя вебмастеров по форумам я именно ей и пугал при разговорах о горячем бэкапе), то пришлось поиграться с её параметрами, так как стандартные в 50-80% от RAM для innodb_buffer_pool_size забивали систему под 500 Mb, и в этом случае параметр skip-innodb убирается
innodb_buffer_pool_size=16M
innodb_additional_mem_pool_size=8M

После перезагрузки система зашуршала, отбирая под себя 440Mb.

Пришлось еще повыкидывать несколько параметров, так что файл приобрел вид:
[mysqld]
local-infile=0
max_connections=300
read_buffer_size=1M
sort_buffer=1M
log-slow-queries
query_cache_limit=256K
key_buffer=1M
innodb_buffer_pool_size=16M
innodb_additional_mem_pool_size=8M
max_allowed_packet=16M

После чего система стартанула уже с 350Mb, с которыми уже можно было в принципе жить.

Хостинг конечно хороший, но как попадешь на тупаря в суппорте, так хоть стой, хоть падай.

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

1. BigDump
Открываем файл скрипта bigdump.php, в котором отыскиваем и меняем следующие строки на необходимые значения
$db_server   = ‘localhost’;
$db_name     = ‘DB_NAME’;
$db_username = ‘DB_USER’;
$db_password = ‘DB_PASSWORD’;
$filename           = ‘OUR_DUMP.SQL’; /* Наш дамп базы данных который мы выгрузили вместе со скриптом*/
$db_connection_charset = ‘Charset’; /*Поскольку мы работаем с русскими базами, то вероятнее всего это utf8 или cp1251*/

После этого открываем в бродилке скрипт хттп://наш-сайт/папка/bigdump.php и видим свой файлец, после чего наживаем на линк Start import

2. Sypex Dumper
С этим скриптом еще проще, так как у него есть графический интерфейс, через который можно вводить все данные, а также делать экспорт и импорт баз данных. Собственно заливаем файлец скрипта dumper.php на хостинг, но с одной оговоркой- опять же в плане кодировок. По умолчанию скрипт работает с cp1251, так что если надо залить utf-8, то добавляем в следующую строку параметр принудительной замены кодировки:
define(‘RESTORE_CHARSET’, ‘forced->utf8′);

После чего коннектимся через бродилку хттп://наш-сайт/папка/dumper.php
вводим логин на базу данных сайта и получаем возможность как импортировать нужную нам базу данных, так и экспортировать.

Поскольку использую нормальные хостинги, то решение это проблемы занимает всего 10-15 минут, так что особо не парился, но тут столкнулся с тем что возникла необходимость подсказать человеку у которого суппорт курил бамбук, так что выделилось несколько вариантов решения данной проблемы. Оговорюсь сразу что наиболее удобен для импорта базы данных mysql последний вариант, но он подходит только тем у кого есть доступ к терминалу. Так что в статье описаны все возможные способы импорта большой базы данных в mysql, кроме общения с суппортом.

1. Варинт первый – выгружаем бэкап базы не целиком, а по несколько таблиц, чтобы файл не превышал наши лимиты. Основной минус данного решения- это то, что операцию выгрузки- загрузки необходимо будет проводить много раз, так что подойдет исключительно для тех у кого много свободного времени и нечем заняться на досуге.

2. Вариант второй – выгружать в пожатом состоянии- так как степень сжатия для текстового файла будет максимальной. Но тут опять же можно столкнуться с тем, что на хостинге не установлена поддержка архиваторов.

3. Используем сторонний скрипт, который позволяет производить экспорт и импорт базы данных, минуя общение с phpMyAdmin. Наиболее известный из имеющихся в наличии, и к тому же наиболее хорошо работающий- это BigDump. О том как его настроить – я отписался чуть позже, так что это касается и настройки по 5му пункту.

4. Как частный случай 3 вариант, возможно залить на сервер эмулятор терминала и сделать 5 пункт через него. Например можно попробовать PHPterm, но в этом варианте можно столкнуться с ограничениями хостинга в плане безопасности запуска команд и скриптов.

5. Также есть простенькая программка аналогичная BigDump, которая также позволяет импортировать большие базы данных, только в данном случае необходим Zend Optimizer либо Nu-Coder. Программка называется Sypex Dumper, и вторую версию скрипта можно даже интегрировать в наиболее популярные CMS. На сайте есть как платная утилита, так и облегченная бесплатная версия.

6. Если таки имеется доступ к консоли, то можно добавить в php.ini следующие строки (увеличиваем лимит загрузки файлов по времени и размеру), после загрузки, лучше вернуть все назад, чтобы не нагнули сервак с оказией:
max_execution_time = 20000
max_input_time = 20000
upload_max_filesize = 150M
post_max_size = 150M

7. Но на самом деле наиболее быстрым и оптимальным вариантом загрузки большой базы данных, имея доступ к консоли, будет загрузить дамп базы данных dump.sql через ftp, а затем залить её через консоль ssh:
mysql -h hostname -u user-name -p DB_name <  /path-to-dir/dump.sql
если у вас в качестве хоста базы данных используется стандартный localhost , то ключик -h можно и опустить, так что получится вида:
mysql -u user-name -p DB_name <  /path-to-dir/dump.sql

Да, чуть не забыл про самые поганые грабли всей пляски с импортом- при импорте базы данных могут возникнуть проблемы с кодировками, поэтому нам надо убедиться что дефолтная база и выгрузка sql находятся в одной кодировке, либо переконвертировать базу данных в стандартную для mysql кодировку (обычно это utf-8):
iconv -f CP1251 -t UTF-8 dump.sql > dump.sql.utf8
либо указать необходимую кодировку при процедуре импорта базы данных:
mysql -h hostname -u user-name -default_character_set utf8 -p DB_name <  /path-to-dir/dump.sql

Но как водится выход есть даже из самой жопской ситуации. То есть если вам необходимо завести пяток сайтов в одной базе, то это возможно сделать. Но надо учитывать несколько моментов:

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

Если вы все же решили что оно того стоит, то создаем базу данных средствами хостинга, после чего закачиваем нужное количество копий wordpress на хостинг, подключаем домены и запускаем установку CMS Wordpress, где для каждой установки указываем различные table_prefix: wp_ ; wp1_; wp2_ и т.п, которые после копируем в файл wp-config.php (в самом файле для копии wordpress эта строка будет выглядеть $table_prefix = ‘wp_’; )

Точно такое же действие подойдет и для других CMS:
в Drupal прописываем в файл sites/default/settings.php аргумент $db_prefix = ‘drupal1_’;
в Joomla в файле configuration.php указываем var $dbprefix = ‘joomla1_’;
После того как запустим установку CMS все необходимые таблицы, с указанными префиксами создадутся установочными скриптами.

Собственно там ничего сложного, особенно если стоит линуксовый установщик yum. Если его естественно нет, то делаем все по старинке:
$ mkdir /usr/local/yum
$ cd /usr/local/yum
$ wget http://linux.duke.edu/projects/yum/download/2.0/yum-2.0.7.tar.gz
$ tar xvzf yum-2.0.7.tar.gz
$ cd yum-2.0.7
$ ./configure
$ make && make install
после чего продолжаем будто yum у нас уже стоял:
$ yum install mysql
$ yum install mysql-server
$ yum install mysql-devel
$ chgrp -R mysql /var/lib/mysql
$ chmod -R 770 /var/lib/mysql
$ service mysqld start
После этого загоняем мускуль в автозагрузку:
$ chkconfig mysqld on && service mysqld restart && chkconfig –list | grep mysqld
После этого задаем пароль для рутового пользователя сервера баз данных:
/usr/bin/mysqladmin -u root password ‘Password’
Затем переходим к созданию необходимой базы данных и пользователя:
$  mysql -u root -p
mysql> CREATE DATABASE ИмяБазы;
mysql> USE  ИмяБазы;
mysql> GRANT ALL PRIVILEGES ON *.* TO Юзер@localhost  IDENTIFIED BY ‘ПАРОЛЬ’ WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;
mysql> \q

После чего можно радоваться тому факту что на нашем дешевом VPS теперь крутится движок баз данных mySQL.

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

Собственно для того чтобы сделать резервную копию сайта- нам необходимо два типа данных- собственно содержимое домашней директории сайта и выгрузка базы данных. Сайт мы копируем по ftp, используя стандартные механизмы протокола, единственно не забывая о том, что если на сайте присутствуют русские имена файлов, то нам необходим ftp-клиент поддерживающий кодировку utf8 (об этом я как раз писал накануне).

Для того же чтобы выкачать базу- нам понадобится утилита управления серверов mysql – phpmyadmin. Естественно, что можно скопировать сайт используя например встроенные утилиты- например для того же Drupal, но во первых они не всегда корректно копируют базу, а во вторых у того пользователя который был у меня на момент выгрузки данных- не было прав на использование этого модуля.

Так что пришлось таки биться с phpMyAdmin. Качаем утилиту с официального сайта, разархивируем её себе на компьютер и редактируем файл конфигурации, предварительно ознакомившись с файлом конфигурации сайта имеющейся резервной копии, на предмет выяснения паролей и явок связи сайта с базой данных. Собственно у каждого движка его расположение свое собственное, поскольку я переносил друпальный сайт, то в моем случае его местоположение было sites/all/default.

Создаем конфиг-файл config.inc.php, из имеющегося config.sample.inc.php, и заполняем строчку
$cfg['blowfish_secret'] = ‘ba17c1ec07d65003′;  // use here a value of your choice
произвольным кодом, который нам будет нужен для аутентификации по кукам. Также мы можем поменять тип аутентификации, в строчке
$cfg['Servers'][$i]['auth_type'] = ‘cookie’;
например на аутентификацию по http, что бы при обращении к странице сразу выскакивал логин-промт:
$cfg['Servers'][$i]['auth_type'] = ‘http’;

Помещаем файл в корневую директорию phpmyadmin. После этого загружаем все содержимое каталога  в подпапку, например phpmyadmin, корневого раздела сайта и заходим через бродилку http://сайт//phpmyadmin. Вводим логин который мы достали из конфига CMS и вуаля- “мы уже а Хопре!”

Вероятнее всего при заходе через бродилку у вас будет ругань следующего содержания: «Расширение mcrypt не найдено. Пожалуйста, проверьте ваши настройки PHP», но её мы просто игнорируем. Также в этой ситуации придется забить и на все остальные варнинги, как то отсутствие библиотеки mbstring, которая также ставится из консоли, и всевозможные опции для утилиты phpmyadmin.

Поэтому проходим в экспорт и цинично сливаем базу данных, выбрав доступный формат сохранения базы данных- как минимум sql.

Год уже работаю с различными буржуинскими хостингами, и очень они мне нравятся во всем: удобство, поддержка, обслуживание, цены, скорости. Поддержка вообще прекрасна- поскольку у большинства из них имеется лайв-чат, что не так, помогут почти мгновенно, или хотя бы просто быстро. Но это если что то простое или стандартное. А вот если возникают какие то сложности, то тогда почти всегда выходило так, что мне быстрее было допетрить самому чем долго и занудно общаться с суппортом. Вот и сейчас- полтора часа ушли на объяснения что и почему и как не работает, консультации с админами на их стороне и прочее, и только когда понял, что со мной работают наотъебись™ , немножко включил мозг- в итоге сделалось все за 5 минут. :-/ Кто вернет полтора часа? Но ладно- это так

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

Вообщем используя Fantastico я снес сайт крутившийся на Joomla.

И сегодня обнаружив пропажу- решил было все исправить. Взял имевшийся у меня бэкап домашней директории, закачал его в нужную директорию, после чего попытался восстановить бэкап базы сайта. Но стандартной восстановлялкой из утилиты Backups в панели управлении хостингом cpanel это не получилось, по не понятным мне, и как оказалось в последствии- техподдержке также, причинам. Тогда в утилите MySQL Databases я создал такую же базу и пользователя, назначив ему права на базу.  После чего я загрузил утилиту phpMyAdmin, доступную в разделе Databases и в ней, выбрав соответствующую базу, с помощью команды Import подтянул базу данных.

Но сайт по прежнему говорил о том, что не может соединиться с MySQL, из чего я сделал вывод, что пароль у меня к базе указан не правильно. А вот как правильно – это мне и предстояло узнать. После того как я перелопатил всю базу Joomla и бэкап общей базы mysql, в которой пароли были хешерованы, я полез собственно в установочную директорию Joomla. И вот в ней, я обнаружил файлик, содержавший всю ту информацию, которую я надеялся найти в базе Joomla, а именно пароли и явки.

Итак, разрешите представить файл %homedir%/configuration.php
Открываем на редактирование и видим много чего интересного, но нас интересуют поля относящиеся к движку mysql.

####################

<?php
class JConfig {

…….

var $dbtype = ‘mysql‘;
var $host = ‘localhost’;
var $user = ‘odminblog_mysqluser’;
var $db = ‘odminblog_jo177′;
var $dbprefix = ‘jo_’;
var $smtphost = ‘localhost’;
var $session_handler = ‘database’;
var $password = ‘Password’;

…..

}
############

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

Выполнив все указанные процедуры я получил работоспособный сайт назад.

Итак установка мускуля. Ставить будем, актуальную на данный момент, версию MySQL 5.1.41. Существует три вида подобной установки и я пойду сверху вниз по мере усложнения.

1. Первый вид, наиболее простой и незатратный. Мы просто скачиваем с офф.сайта полностью откомпилированный сервак и распаковываем его у себя на сервере. Откровенно говоря я больше предпочитаю этот вариант поскольку он наиболее быстрый и надежный, тем более думаю что инженеры Sun однозначно не хуже меня соберут необходимый продукт. Тем более что этот способ позволяет получить наиболее актуальную версию продукта, более свежую, чем будет установлена, например, из портов. Единственно что, он устанавливается в максимальной комплектации и идет с подключением всех возможных модулей.

# wget http://dev.mysql.com/get/Downloads/MySQL-5.1/mysql-5.1.41-freebsd7.0-i386.tar.gz/from/http://www.mirrorservice.org/sites/ftp.mysql.com/
# tar -xzvf mysql-5.1.41-freebsd7.0-i386.tar.gz
# mv ./mysql-5.1.41-freebsd7.0-i386 /usr/local/mysql

Добавляем в систему пользователя и группу от которой будет работать демон mysqld, наречем его mysql. Зададим  ему права на папку хранения баа данных, по умолчанию, и создадим первичный комплект БД MySQL.

# cd /usr/local/mysql
# chown -R mysql:mysql /usr/local/mysql/*
# scripts/mysql_install_db –user=mysql
# chown -R root .
# chown -R mysql data

Прописываем скрипт запуска сервера
# cp support-files/mysql.server /usr/local/etc/rc.d/

2. Этот способ lyssara-style, т.е. установка из портов. Выбираем версию сервера 5.1, на данный момент актуальной является версия 5.1.41

# cd /usr/ports/databases/mysql51-server/
# make && make install && make clean

##### Используемые по умолчанию параметры установки #####
WITH_CHARSET=charset    Define the primary built-in charset (latin1).
WITH_XCHARSET=list      Define other built-in charsets (may be ‘all’).
WITH_COLLATION=collate  Define default collation (latin1_swedish_ci).
WITH_OPENSSL=yes        Enable secure connections.
WITH_LINUXTHREADS=yes   Use the linuxthreads pthread library.
WITH_PROC_SCOPE_PTH=yes Use process scope threads
(try it if you use libpthread).
BUILD_OPTIMIZED=yes     Enable compiler optimizations
(use it if you need speed).
BUILD_STATIC=yes        Build a static version of mysqld.
(use it if you need even more speed).
WITHOUT_THR_ALARM=yes   Disable signals (this reduces kernel lock
contention on SMP, but has the side effect
that you can’t kill clients that are sleeping).
WITHOUT_INNODB=yes      Disable support for InnoDB table handler.
WITH_ARCHIVE=yes        Enable support for Archive Storage Engine.
WITH_CSV=yes            Enable support for CSV Storage Engine.
WITH_FEDERATED=yes      Enable support for Federated Storage Engine.
WITH_NDB=yes            Enable support for NDB Cluster.
#####################################################
Смотрим файл Makefile и выбираем те параметры что интересуют нас и записываем их в /etc/make.conf  У меня получилось следующее:
###########

.if ${.CURDIR} == ${PORTSDIR}/databases/mysql51-server
WITH_CHARSET=utf8
WITH_XCHARSET=all
WITH_COLLATION=uft8_bin
WITH_LINUXTHREADS=yes
BUILD_OPTIMIZED=yes
BUILD_STATIC=yes
WITHOUT_INNODB=no
.endif
.if ${.CURDIR} == ${PORTSDIR}/databases/mysql54-client
WITH_CHARSET=utf8
WITH_COLLATION=utf8_bin
BUILD_OPTIMIZED=yes
.endif

###########
Копируем скрипт загрузки в rc.d
# cp /usr/local/share/mysql/mysql.server /usr/local/etc/rc.d/

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

# tar -xzvf mysql-5.1.41.tar.gz
# cd mysql-5.1.41
Смотрим доступные для установки опции
# ./configure –help
Создаем шаманскую фразу призывающую демона MySQL снизойти на наш сервер
# ./configure –prefix=/usr/local/mysql –localstatedir=/usr/local/mysql/data –with-mysqld-user=mysql –with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock –with-charset=utf8 –with-extra-charsets=all –with-error-inject
# make && make install && make clean
# sh scripts/mysql_install_db

Теперь после того как мы поставили MySQL всеми этими различными способами, переходим к правке конфиг файла
# vi /usr/local/etc/my.cnf
####### Подробные описания параметров на офф.сайте MySQL

# Раздел настроек клиента MySQL
[client]
# Указываем сокет сервера, к которому следует обращаться.
# Можно также указать порт, на котором будет крутиться сервер,
# но поскольку мы планируем использовать сервер MySQL
# для локальных баз, то закомментируем эту директиву
# port = 3306
socket = /tmp/mysql.sock
# Указываем пароль для подключения к БД, если используем
# password = your_password

# Настройки сервера MySQL
[mysqld]
# Расположение баз данных MySQL
datadir=/usr/local/mysql/base
# Расположение сокета
socket=/tmp/mysql.sock
# Пользователь от которого запускается демон MySQL
user=mysql
# Адрес и порт на которых демон слушает обращения (для локальной базы
# оставляем 127.0.0.1 или не используем вовсе)
bind-address = 127.0.0.1
# port = 3306
# Размер блока для таблиц типа MyISAM- тот буфер памяти
# который система использует для индексирования. Максимальный размер
# на 32-битных платформах 4Gb. Обычно задают порядка
# 25% размера оперативной памяти.
key_buffer_size=50M
# Максимальный размер пакета. Изначально размер пакета
# задается параметром net_buffer_length, но в случае необходимости
# может возрасти до max_allowed_packet.
# Этот параметр, по умолчанию, задается небольшого значения,
# для отлова больших (предположительно ошибочных) пакетов.
max_allowed_packet = 1M
# Количество максимальных разрешенных клиентских сессий.
# По умолчанию этот параметр равен 100
max_connections=300
# Увеличение этого параметра увеличивает количество
# дискриптеров необходимых для mysqld.
# Выяснить необходимость увеличения табличного кэша,
# можно путем проверки статуса Opened_tables
table_cache = 4
# Каждому потоку, производящему операцию сортировки,
# выделяется буфер заданного размера. Увеличение этого параметра
# ускоряет выполнение операций ORDER BY и GROUP BY
sort_buffer_size = 1M
# Каждому потоку производящему операцию последовательного сканирования,
# выделяется буфер заданного (в байтах) размера,
# для каждой сканируемой таблицы.
# При множественных последовательных сканированиях, значение параметра
# имеет смысл увеличить, т.к. по умолчанию он равен 131072.
read_buffer_size = 1M
# При сортировке прочтенных строк происзводится операция ключевой сортировки,
# при которой строка считывается через заданный буфер,
# во избежании поиска на диске.
# Большое значение данного параметра способно значительно увеличить
# производительность операции ORDER BY.
read_rnd_buffer_size = 256K
# Каждый клиентский поток соотносится с буфером соединения и
# результирующим буфером. Оба они имеют размер заданный данным параметром,
# но при необходимости могут динамически увеличиваться,
# вплоть до величины заданной параметром max_allowed_packet.
# Каждый результирующий буфер сокращается до величины net_buffer_length
# после каждого SQL отчета.
net_buffer_length = 2K
# Этим параметром задается размер стека для каждого потока.
# Большое количество ограничений, обнаруживаемых тестом crash-me,
# зависит от значения этого параметра.
# Значения по умолчанию (192Kb) достаточно для нормальных операций.
thread_stack = 64K
# Не использовать системные блокировки
skip-locking
# Данный параметр, в режиме ON, используется для работы локальной БД,
# т.е. сервер MySQL не использует стек TCP/IP,
# а работает только через файл сокета.
# Данный параметр задается при конфигурации опцией
# –skip-networking (как и все  доступные опции)
skip-networking
# Не резолвить доменные имена клиентов, и использовать только IP.
# Если используется этот параметр то поле Host в таблице
# разрешений (grant table) должно содержать только IP адреса или localhost
skip-name-resolve
# Отключение поддержки BDB (Berkeley DB), в том случае если нет
# необходимости поддержки BDB таблиц. Этот параметр позволяет сэкономить
# память и тем самым ускорить выполение некоторых операций.
skip-bdb
# Путь хранения лог файла (у пользователя mysql должны быть права на запись)
log-error=/var/log/mysql.errors

##########################################################

Вроде как все готово, можно запускать в плавание. Первый запуск осуществим командой:
# bin/mysqld_safe –user=mysql &
Дальнейшие манипуляции с сервером MySQL будем производить посредством запускающего скрипта
# /usr/local/etc/rc.d/mysql-server [fast|force|one](start|stop|restart|rcvar|status|poll)
Смотрим- все ли у нас запустилось:
# ps -axj | grep mysql

И начинаем размышлять, что теперь к этому серверу мы можем прикрутить.

К большому сожалению база InnoDB работает по принципу ниппеля, т.е. туда дуй, оттуда х… Объясняя это доступным языком- табличное пространство может как расширяться так и уменьшаться, но физический размер базы при этом изменяется только в сторону увеличения. Проще говоря если у вас база была на максимуме 20гигов, и после этого вы её почистив освободили 90% пространства, внутри база у вас будет свободна на 90% (посмотреть свободное пространство можно командой в консоли управления сервером: mysql> show table status; ), но снаружи она так и будет занимать на диске 20 Гиг физического пространства диска. Так вот у меня, на одном из серверов, она успела разрастись, пока я прочухал тот факт, что забыл установить чистящий скриптик, до 250 Гигов, которые конечно работают как часы, но самой цифрой действуют мне на нервы. В этой связи надо что то делать. Но делать можно только одним способом, а именно перегнать базу в дамп sql и затянуть его обратно, предварительно дропнув имеющегося монстра. В этой связи, ровно как и для дефрагментации табличного пространства, нашим лучшим другом является системная утилита mysqldump, входящая в стандартный комплект поставки сервера mySQL.

*** Для дефрагментации InnoDB также можно использовать способ двойной перегонки базы, с помощью команды ALTER преобразовать её в тип MyISAM, а затем обратно в тип InnoDB.
Данная утилита дает возможность сделать мгновенный слепок базы данных (на тему мгновенности конечно это я так, для красивого словца- полтора гига шло минут 7, 250 прошли за 2.5 часа) представляющий собой текстовый файл с набором SQL команд для создания и заполнения таблиц.
Собственно приступаем к работе:

# mysqldump -uSQL_USER_EXIM -p EXIM_DATABASE > /tmp/exim.sql

-u или –user=  – имя пользователя
-p –password  -  запрос пароля
exim_database – имя базы данных
exim.sql – файл для вывода дампа

за раз можно загнатьв дамп несколько баз, если перечислить их друг за другом, после опции -B или –databases:

# mysqldump -uSQL_USER_EXIM -p database1 -B database2 database3 > /tmp/database.sql

также можно снять дамп всех таблиц, если использовать оператор -A или –all-databases:

# mysqldump -uSQL_USER_EXIM -p -A > /tmp/database.sql

Данная операция займет некоторое время и место на диске, зависящее от объема базы SQL.

После этого останавливаем сервер mySQL

#  /usr/local/mysql/support-files/mysql.server stop

*****
С версии 6.x доступен так называемый on-line backup для всех типов баз. Его отличительные особенности то, что он не блокирует выполнение INSERT/UPDATE/DELETE и выполняется простейшими командами:
BACKUP DATABASE <db_name> to <file>
RESTORE <file> [OVERWRITE]
*****

Делаем резервную копию базы данных которую мы предполагаем экспортировать, из папки %mysql%/data переписываем файл базы и журналов InnoDB и соответствующую ей папку с файлами *.frm в самое укромное место на винте.

После этого удаляем таблицу и соответствующие ей файлы, и запускаем сервер:

#  /usr/local/mysql/support-files/mysql.server start

Сервер немного подумает и восстановит пустую базу InnoDB, после чего мы заливаем в неё наш бэкап. Сделать это можно двумя способами, либо из командной строки:

# mysql -uSQL_USER_EXIM -p EXIM_DATABASE < /tmp/exim.sql

либо из консоли сервера:

mysql> use EXIM_DATABASE;
mysql> source exim.sql

После чего смотрим производительность и размер диска, занимаемый базой.
******
Парочка полезных советов:

При ограниченных ресурсах памяти или объемной базе данных, следует использовать опцию –quick или –opt, это позволит утилите mysqldump начать делать дамп базы без предварительной загрузки её в память.

Также может возникнуть необходимость указания кодировки в которой вы хотели бы получить дамп вашей базы, для этого используется опция –default-character-set=

Опция -f позволит продолжать выполнение резервирования даже при получении ошибки в ходе выполнения процедуры.

Удобная команда для автоматического резервирования со сжатием:
mysqldump -uROOT -pPASSWD DBNAME | gzip -c > `date “+%Y-%m-%d”`.gz

Также возможно резервироватьна удаленный хост:
mysqldump -uROOT -PNUMBER_PORT -hHOST -pPASSWD DBNAME