Решение есть. Но в то же время есть ещё одна тонкость. DBB::mysql драйвер имеет опцию автореконнекта (mysql_auto_reconnect) и будет следить за актальностью handle и при случае переконнектится. Но вот что делать с коммандами, которые иногда надо выполнить сразу после коннекта, например SET NAMES ‘utf8′;SET CHARACTER SET ‘utf8′ ? И тут есть решение! Хотя найти его не всегда легко в интернет

Вообщем, вот код для коннекта из под Perl к MySQL так, чтобы всё работало пучком:

$dbh = DBI->connect( "dbi:mysql:database=database_name;mysql_client_found_rows=1;mysql_enable_utf8=1;mysql_socket=/socket_of_mysql", 'user', 'password',
    {
	RaiseError		=> 1,
	AutoCommit		=> 1,
	mysql_multi_statements	=> 1,
	mysql_init_command	=> q{SET NAMES 'utf8';SET CHARACTER SET 'utf8'}
    } ) or die "Cannot connect";
$dbh->{mysql_auto_reconnect} = 1;

Код проверен мною и тщательно протестирован

В MySQL есть такая особенность для таблиц типа MyISAM — операции изменения таблицы (INSERT/UPDATE/DELETE) имеют более высокий приоритет перед SELECT. Представим себе такую картину: к MySQL поступает сразу несколько запросов  в таком порядке: SELECT (1) -> UPDATE (2) -> SELECT (3) -> SELECT (4). Все эти запросы — от нескольких клиентов (сессий) и все — на работу с одной и той же таблицей (для простоты понимания). Первый SELECT, предположим, занимает 2 сек времени на выполнение. Если бы не было UPDATE, то остальные селекты могли бы исполняться в параллель — таблица ведь не меняется, данные тоже, почему бы не дать другим клиентам тоже выполнить запросы… Но, поскольку, есть UPDATE (то же было бы для случая DELETE/INSERT), MySQL заблокирует таблицу полностью при первом же случае (в нашем примере сразу же после отработки первого SELECT, который поступил раньше UPDATE), т.е. он ждет выполнения первого селекта (2 сек) для блокировки. За эти две секунды никто не может получить доступ к таблице, остальные SELECT будут ждать выполнения UPDATE (вень у него более высокий приоритет пол умолчанию), а UPDATE ждет первого SELECT. Все… Это пипец… Если у вас не загруженный сервак, то вас это беспокоить не будет — никто не будет наступать друг другу на пятки. А если сервак загружен, эту ситуацию можно сравнить с давкой в торговом центре, где ажиотаж, но при этом security решили пропустить без очереди VIP персону…

Какой выход? Оказывается, довольно простой. Один из вариантов — изменить по умолчанию приоритет операций для изменения таблиц (т.е. для UPDATE/INSERT/DELETE) — опция --low-priority-updates при запуске mysqld. Но это слишком глобальный способ, и вряд ли хороший. Я не вдумывался в его смысл, но думаю, раз придумали такой приоритет, то значит это кому то нужно.

Есть способ второй — найти такие узкие места в программе, где есть вместе долгоисполняемые SELECT (например большие JOIN), а также где рядом исполняется INSERT/DELETE/UPDATE на те же таблицы. И вот для тех INSERT/DELETE/UPDATE добавить слово LOW_PRIORITY в запросе. И все! На 99% вы устраните это узкое место и будете удивлены, насколько все пропрет Представим, что будет после. Если встретился долгий SELECT, а поступил также, например UPDATE, но уже с LOW_PRIORITY, а за ним в очереди другие SELECT, то другие SELECT будут исполняться сразу же в параллель вместе с первым длинным по времени, даже пока он не закончился. А уже после будет работать UPDATE и никому не мешать. Вообще, есть больше рекомендаций от самой MySQL.ORG.

Итак, что же это за такая rsync? Это действительно, утилита рекурсивного копирования (копирует все файлы и поддиректории) с одного хоста на другой, или даже внутри одной машины. На этом все ее отличие от, например, утилиты cp заканчивается. И вот тут самое интересное — она при копировании каждый файл или директории, которые копируем, проходит блоками, и отслеживает только изменения блоков в сравнении с уже скопированными блоками. Грубо говоря, она копирует только «дельты» файлов и директорий! Что это значит? Это значит, что второй, третий и так далее запуски этой программы на определенную цель (куда копировать) будут занимать гораздо меньше времени, операций копирования и передачи данных по сети при повторном копировании уже изменившихся файлов. Вот несколько примеров ее использования:

1) Быстрый перенос баз данных (на примере SQL).

Имеем два сервака — один рабочий A, второй Б — куда будем резервировать свои базы данных (там где нет работающего SQL). Тогда для резервирования можно периодически запускать rsync на сервере A, не прекращая работы SQL сервера (назовем это «рабочим резервом»). Но чтобы нам иметь полностью правильные базы в резервной директории сервера Б, нам надо временами останавливать SQL на серваке А, и пока там нет работаюшего SQL, делать повторное копирование (назовем это «фиксированным резервом»). Вот тут то rsync и пригождается! Во время «рабочего резерва» многие файлы успевают устареть, ведь SQL продолжает работать. Во время «фиксированного резерва» копируются только дельты с последнего запуска «рабочего резерва». Если время между этими запусками мало, то дельты копируются очень быстро — на больших базах это может быть не более минуты, например. Для снижения времени простоя, надо просто выполнить повторный «рабочий резерв» прямо перед остановкой MySQL сервера. Плюсы такого способа — минимальный даун по времени, минимум человеческих ошибок, простота. Я не знаю другого способа на данный момент, чтобы сделать быстрый резерв больших баз данных на другую машину, и при этом свести время простоя к минимуму.

Команды (смотрите не перепутайте! Тут все как в теории относительности )
На стороне сервера Б (можно и на стороне А, но тогда надо поменять пути местами), куда копируем, запускаем команды копирования во время «рабочего резерва»

cd
nohup /bin/nice -n 20 ionice -c3 rsync --rsync-path='/bin/nice -n 20 ionice -c3 rsync' -avz --delete IP.ADDRESS.SERVER.A:'/path/to/source/folder/' /path/to/target/folder/

Краткие пояснения (ВАЖНО):
Некоторые утилиты могут отсутствовать, примеры даны для Linux! Здесь nohup — «оторвать» ввод/вывод от терминала. Это нам потребуется, когда мы захотим оставить запущенный «резерв» в фоновом режиме. Сразу мы не можем этого сделать (то есть не ставлю ‘&’ в конце), так как rsync при копировании использует ssh, и раз мы копируем на другой сервак, он запросит у нас пароль (если авторизация через openssh ключи + ssh-agent, то можно и поставить ‘&’, но об этом в другой раз, в другой статье). После ввода пароля уже можно будет нажать Ctrl+Z в shell и затем "%1 &" для запуска в фоновом режиме первой запущенной задачи (см. man bash). Команда nice — выставить приоритет для процессора, а ionice — приоритет для операций при работе с диском — все приоритеты ставяться на понижение, чтобы продолжалась нормальная работа сервера. Опция --delete для rsync — удалять все файлы в целевой директории (от слово «цель», target), которых нет в исходной (source). То есть, после копирования получим полностью равную директорию по содержанию.
Слеш в конце исходной директории (/path/to/source/folder/)  — важная штука! Если в конце слеш — директория рассматривается rsync-ом как комплект директорий и файлов в ней для копирования, а если слеша нет — как один объект, целая директория со своим именем — в обоих случаях копирование рекурсивное, но если из примера убрать слеш в конце первого пути (сделать /path/to/source/folder), то в /path/to/target/folder/ будет создана папка folder и туда скопируется ее содержимое! Почитайте man-ы, если хотите понять, как присутствие или отсутствие слешей в конце директории влияет на ход событий

2) Перенос сайтов.

Способом, описанным выше, также можно переносить и сайты вместе с их базами. Для баз мы используем способ выше, а для переноса контента делаем все то же самое, но при работающем apache. Как и в первом способе, apache мы останавливаем только на несколько минут или секунд, быстро запускаем rsync для «фиксированного резерва», а после окончания запускаем apache снова. После остается сменить только DNS на новый IP адрес и все! Для повышения скорости переноса не забудьте за неделю до переноса выставить часовой TTL в вашем DNS для SOA записи зоны и для всех ее остальных записей. Тогда при смене IP весь трафик на сайт переместится за один час! Но это, как говориться, уже другая история.

Если вы работаете раз от разу в bash, tcsh и других shell-ах, вы можете не знать про следующие, но очень удобные команды, которые облегчать вам жизнь под Unix:

• Ctrl + A — переход в начало текущей строки;
• Ctrl + E — переход в конец текущей строки;
• Стрелка вверх / Стрелка вниз - хождение по history командам соответственно к более старым командам / к более новым (это вы навярняка знаете)
• Ctrl + U — стирает все слева от текущей позиции курсора, то есть чтобы быстро очистить строку, можно сделать Ctrl + E и затем Ctrl + U
• Esc -> d — стирает слово справа (сначала нажимаем Esc, отпускаем, затем ‘d’)
• Tab - формирует законченный вид не до конца набранной команды, файла или директории. Для MySQL -  еще таблицы, имени колонки. Если нет однозначности, то после повторного нажатия Tab выдаются варианты. Очень ускоряет процесс работы в командной строке, если вы не знали про это
• Ctrl + PageDown - переход к самой последней (свежей) команде в history
• Ctrl + PageUp - переход к самой старой (первой) команде history
• Ctrl + R - самая ценная команда для меня — поиск в history. Делается так: нажимаем Ctrl + R, появляется приглашение ввести подстроку поиска ( (reverse-i-search)`’: ), далее мы вводим, например, «mysql» — видим самую последнюю команду shell-а, где встречалось подстрока «mysql». Если она нас не устраивает, то для повтора поиска тут же надо снова нажать Ctrl + R. Каждое нажатие Ctrl + R перемещает нас к более старым командам с подстрокой «mysql», которые мы когда либо исполняли. Если же нас найденная команда устраивает, нажимаем «Стрелка вправо» или «Стрелка влево» и приступаем к редактированию и исполнению команды. Это очень удобная и нужная команда!

Все эти команды — подмножество команд библиотеки readline (man 3 readline). Ее используют и другие программы, например MySQL. Но в MySQL есть то ли баг, то ли так задумано разработчиками. Суть ее в том, что MySQL версий 3.x, например, прекрасно исполнял команду поиска (Ctrl + R), но потом, по каким то причинам, новые релизы — MySQL 4.x & 5.x перестали работать с поиском. Скорее всего, это связано с тем, что раньше MySQL использовал readline библиотеку, но потом разработчики перешли на editline. И последняя перестала работать с поиском. Я долго мучался, пока не нашел решение. Оно следующее:

Создать файл ~/.editrc — конфиг для editline. Там мы пишем следующие строки:

bind "\e[3~" ed-delete-next-char
bind "^R" em-inc-search-prev

После этого в MySQL 4.x & 5.x у нас будет работать Ctrl + R.

Другим решением для MySQL вместо редактирования .editrc будет использовать rlwrap программу (установка в Linux Fedora Core, например, такая: yum install rlwrap) — она «обертывает» stdout запускаемой программы и создает history для вводимых строк (хранит в ~/.commandname_history). У нее есть некоторые недостатки — на ввод паролей она делает echo, то есть пароль будет виден на экране. Можно с помощью опций отключить это, но это не идеально. Зато можно в нее обернуть любую программу, которая даже не имеет history вообще (rlwrap perl -MCPAN -e shell , например). Итак, второе решение для MySQL может быть таким:

alias mysql=’rlwrap -a mysql’

Это ставиться в ~/.bashrc, например. Или вместо алиаса можно просто запустить:

rlwrap -a mysql -uroot -p mysql

Man на rlwrap вы можете найти на сайте разработчика.

Вот такие вот тонкости, которые на 100% облегчат вам работу в Unix.