Вчера предо мной была поставлена задача - получить из имеющегося sql дампа базы данных MySQL - базу данных в MSSQL. Обратившись к всемирному разуму в виде поисковика Google - я нашел решение данной проблемы. ...читать далее "Миграция баз данных (MySQL -> MSSQL)"
Метка: MySQL
Архивация InnoDB таблиц в MySQL
После установки MySQL на FreeBSD и переноса основной базы данных программы управления клубом туда, я, будучи из тех админов, что "уже делают бэкапы", озаботился резервным копированием этой базы данных.
Естественно, что в первую очередь, на что упал мой взгляд - это скрипт, идущий в комплекте с MySQL - mysqldump. Внимательно почитав его мануал, и ознакомившись с опытом его применения в производственных средах, опубликованным в различных блогах и сайтах, я понял:
- использование этого скрипта является довольно ресурсоемкой процедурой
- использование этого скрипта с БД, хранящей данные в InnoDB, не гарантирует благополучного восстановления данных без применения нетривиального шаманства
- использование этого скрипта требует остановки демона MySQL
Исходя из вышеназванных причин, с учетом крайней ограниченности в ресурсах и, вероятно, в лени - этот скрипт для меня неприменим. Следовательно, пришлось снова обратиться к мировому разуму, а если быть точнее, к верному поисковику Google с переформулированным запросом.
Итак, вот выход, придуманный не мной, а светлыми головами из Percona - XtraBackup.
Вся дальнейшая информация, точнее та часть ее, что я скопировал - является просто копипастом записи в блоге Highload Web.
XtraBackup - резервное копирование для innoDB
системах с высокими нагрузками особое внимание следует уделять резервному копированию (бекапам) данных. Зачастую самая важная часть данных находиться в СУБД. Проблема заключается в том, что копирование данных нужно проводить незаметным для работающей системы образом. Блокировка данных на момент создания бекапа тут не работает, т.к. время блокирования будет неприемлемым.
Одним из популярных решений является репликация, которая обеспечивает высокую степень надежности и почти нулевую потерю данных при сбое основного сервера. Но репликация требует аппаратных затрат, к тому же резервный сервер должен не уступать по характеристикам основному серверу, иначе от репликации не будет толку.
Другой подход резервного копирования - это использование специальных утилит, которые позволяют делать снимки состояния СУБД на жесткий диск, и восстанавливать состояние обратно по такому снимку. На этом остановимся подробнее.
Поскольку MySQL является одним из самых популярных решений в Web’е сегодня, рассмотрим инструменты для бекапов для этой СУБД.
XtraBackup - это утилита от Percona Labs, предназначенная для горячих бекапов таблиц InnoDB и XtraDB.
Советую всем ознакомиться - весьма-весьма полезно... Однако, есть версия только для 64 битных систем
Похожие записи
Установка MySQL на FreeBSD
Я рад Вам, мои читатели, представить давно обещанную статью об установке MySQL на компьютер под управлением FreeBSD. Расскажу о том, с какими проблемами я столкнулся и какими способами я их решал.
В первую очередь, представлю подопытного:
FreeBSD some_name 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #0: Thu Sep 3 16:32:37 EEST 2009 root@some_name:/usr/obj/usr/src/sys/ROUTER i386. Он давно и успешно трудиться как роутер в одном из наших Интернет-клубов, и отлично справляется с возложенной на него задачей. А раз это ему под силу, то и небольшую базу данных, для управления клубом, он тоже вполне может потянуть, потому что доменный контроллер с сервером антивируса и сервером программы управления клубом уже не справлялся с возложенными на него задачами.
Когда то, давным-давно я уже пытался провернуть эту идею - установку MySQL на него, но что-то не заладилось (что именно, я не припомню, но, судя по всему, мне просто не хватило знаний и настойчивости) и я отложил эту идею.
Итак, у меня есть готовый файл my.cnf (настройки, рекомендуемые производителем программы управления клубом). Я его просто вставил в /etc и исправил пути.
Перед тем, как собственно устанавливать из портов MySQL - сперва нужно эти самые порты обновить:
portsnap fetch
Давненько я систему портов не обновлял, но этому есть одно простое и элегантное объяснение - несмотря на то, что обновление таким способом занимает весьма порядочно времени, оно экономит, в первую очередь, мой траффик, так как в Беларуси, к моему большому сожалению, нету возможности поставить в клуб нормальный, быстрый и достаточно недорогой анлим, чтобы поддерживать систему в адекватном состоянии посредством того же CVSUp.
Фетчим 10 382 новых порта - есть время покурить, поспать, поесть :-).
portsnap extract
portsnap fetch update
"Раз пошла такая пьянка, режь последний огурец" - проверим систему на наличие известных уязвимостей в установленных портах при помощи порта portaudit, командой portaudit -Fda. После проверки, уязвимостей обнаружено не было, что есть приятно.
Собственно, сам процесс установки MySQL сервера 5.0.90 из портов:
Рассказывать буду так, как делал сам.
cd /usr/ports (тут все порты находяться)
make search name=mysql | grep mysql-server: для того, чтобы отсортировать выдачу, с тем, чтобы не искать в огромном количестве
В итоге, нахожу подходящую версию - cd по пути, указанному в выдаче make search и make install.
Опять таки, есть некоторое время для того, чтобы покурить/поспать/перекусить, пока скачается, скомпилируется и установиться.
Собственно говоря, на этом установка завершена и можно поработать с самой базой...
mysqld_safe & запустит сервер mysql в фоновом режиме.
Тут я столкнулся с первой проблемой - сервер стартует и тут же отключает.
Проверив файл some_name.err, который mysql сервер создал, я обнаружил, что он не может прочитать файл /etc/my.cnf - неверно выставлены права на него (юзер mysql должен иметь возможность прочитать этот файл). Попутно проверил юзер mysql использовать папку, где должна храниться БД со всеми правами.
Итак, права выставлены верно - запускаем MySQL снова - mysqld_safe &.
Все запустилось и работает, файлы InnoDB создались, полет нормальный. Теперь, нужно создать пользователя, который сможет писать в БД с удаленного хоста:
mysql (консольный клиент MySQL) -u root (подключаюсь под пользователем root)
Если бы я все сделал правильно, то я бы смог зайти как пользователь root@localhost (изначально он без пароля) и задать ему пароль командой > update user set password=PASSWORD(”newrootpassword”) where user=’root’;, однако, в ходе предыдущих экспериментов, я что то напутал и мне сказали, что access denied
Для того, чтобы исправить эту досадную оплошность - останавливаю сервер MySQL (killall mysqld) и запускаю его командой mysqld_safe --skip-grant-tables &: эта команда позволяет пропустить загрузку таблиц, в которых указаны пароли.
mysql -u root - я подключился к серверу
> Flush priviliges; - эта команда загружает те самые таблицы, в которых указаны привилегии и пароли пользователей
Очень важно использовать mysql-клиент, который не разрывает соединения после выполнения команды, иначе опять окажемся в ситуации, когда у нас спрашивают пароль root, а мы его не знаем.
> GRANT ALL PRIVILEGES ON *.* TO root@localhost IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
> GRANT ALL PRIVILEGES ON *.* TO some_user@"some_host" IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
Проверил, SELECT * FROM user; что может user root и тот, которого я создал…
Все это делается для того, чтобы root'ом можно было зайти только с localhost, а второй пользователь мог бы зайти с удаленного хоста, расположенного в локальной сети.
Достаточный уровень безопасности, для сети такого уровня, обеспечит ipfw, запрещающий входящие соединения на порт, который слушает демон MySQL (3306) всем, кроме доверенного хоста: deny tcp from not хост_которому_можно_подключиться to me dst-port 3306
Итак, пользователи созданы, сервер вроде как стартует - осталось добавить строчку его запуска в /etc/rc.conf и перезапустить компьютер: mysql_enable=”YES” и reboot .
Машинка перезагрузилась, пинг и доступ в интернет появились, даже к MySQL я смог подключиться удаленно, а вот доступа по ssh нет - Putty любезно сообщил мне, что отклика от машины на порту нет, из чего я сделал вывод, что демон sshd не запустился, по каким то причинам. Подключаю монитор, и вижу строчку о том, что скрипт /usr/local/etc/rc.d/mysql-server отлично выполнился, но не передал управление дальше по команде и не ушел в фон, а остался висеть на foreground, не давая тем самым запуститься демону sshd. Скипаю скрипт (Ctrl+C), mysqld и доступ к MySQL сохраняется, sshd стартует - из чего делаю вывод, что нужно изменить сам скрипт mysql-server.
Редактирую, убираю строчку с параметрами запуска (нужные мне параметры описаны в /etc/my.cnf), а после строчки вызывающий mysqld_safe - добавляю амперсанд (&).
Вуаля, после перезагрузки все проходит штатно, MySQL стартует, уходит в фон и передает управления дальше - что и требовалось получить.
З.Ы. Я не претендую на то, что эта статья является единственно верным руководством для установки MySQL сервера в среде FreeBSD. Надеюсь, она поможет кому либо, кто столкнется с похожими проблема. В конце концов, она поможет мне в будущем, когда я опять столкнусь с чем-либо схожим. Однако, если у Вас есть советы - я буду рад получить их тут в комментариях. Спасибо большое...
И, напоследок, маленький анонс - обещаю в ближайшее время написать статью, о том, как бэкапить базы данных MySQL.
deny tcp from not хост_которому_можно_подключиться to me dst-port 3306