The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Частичное восстановление данных MyS..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Частичное восстановление данных MyS..."  +/
Сообщение от auto_tips (??) on 04-Апр-12, 17:28 
Я не буду описывать процесс создания резервной копии MySQL с применением менеджера томов LVM. В интернете хватает описаний этой методики. Предположим у вас уже есть бэкап, который содержит бинарные файлы баз данных. В моем случае они хранятся на выделенном сервере. Использование бинарных файлов позволяет быстро восстановить все базы на момент создания резервной копии, но вот что делать если нужно восстановить только часть баз или только одну, или же только пару таблиц или несколько удаленных записей из таблиц?

Конечно можно поднять отдельный MySQL сервер на другом сервере, скопировать туда бэкап и после запуска вытащить из него нужные данные посредством mysqldump. Но что делать, если другого сервера нет или версия MySQL сервера содержит патчи, которые делают резервную копию несовместимой с дистрибутивной версией? Я постараюсь дать одно из возможных решений этой проблемы.

В своем способе я также буду запускать отдельную копию MySQL сервера, но основная идея заключается в том, чтобы не копировать данные из бэкапа, а примонтировать их через сеть. Я буду использовать sshfs для этих целей. Чтобы при запуске второго сервера не изменились данные в бэкапе я применю оверлей на базе AUFS. Одна из его частей будет примонтированным бэкапом, а вторая - хранить все изменения относительно бэкапа. Таким образом я избегаю любых модификаций резервной копии.

   # mkdir /mnt/mysql-{backup,datadir,tmp}
   # sshfs root@backup.server:/backup/mysql-server /mnt/mysql-backup
   # mount -t aufs none /mnt/mysql-datadir -o dirs=/mnt/mysql-tmp:/mnt/mysql-backup=ro
   # mysqld_safe --defaults-file=/root/mysql-backup-restore.cnf

/root/mysql-backup-restore.cnf - конфигурация для второго сервера, которую я сделал на базе конфига из дистрибутива.

   [mysqld]
   user=root
   pid-file        = /root/mysql-restore.pid
   socket          = /root/mysql-restore.sock
   basedir         = /usr
   datadir         = /mnt/mysql-datadir
   tmpdir          = /tmp
   language        = /usr/share/mysql/english
   skip-networking
   skip-external-locking
   key_buffer              = 16M
   max_allowed_packet      = 16M
   thread_stack            = 192K
   thread_cache_size       = 8
   myisam-recover         = BACKUP
   query_cache_limit       = 1M
   query_cache_size        = 16M
   expire_logs_days        = 10
   max_binlog_size         = 100M
  
   [mysqldump]
   quick
   quote-names
   max_allowed_packet      = 16M
  
   [isamchk]
   key_buffer              = 16M
  
   !includedir /etc/mysql/conf.d/

После запуска вторая копия MySQL сервера доступна только через сокет /root/mysql-restore.sock, чем позволяет исключить посторонний доступ на время восстановления данных. Чтобы подключиться к запущенному серверу, нужно явно указать сокет:

   # mysql -S /root/mysql-restore.sock
   # mysqldump -S /root/mysql-restore.sock --add-drop-table dbname table1 table2 > dbrestore.sql

После того, как данные сняты посредством mysqldump нужно остановить вторую копию сервера. Для этого нужно выполнить:

   # mysqladmin -S /root/mysql-restore.sock shutdown

Когда дополнительный сервер остановится можно отмонтировать /mnt/mysql-datadir и /mnt/mysql-backup, и удалить директории /mnt/mysql-{backup,datadir,tmp}

Несомненным преимуществом такого подхода является время, которое тратится на частичное восстановление резервной копии. Из недостатков пожалуй отсутствие sshfs и aufs во многих дистрибутивах (для centos я так и не смог найти пакета для добавления поддержки aufs). Возможно его следует заменить на любую другую реализацию union fs, но я это делать не пробовал.

URL: http://blog.tataranovich.com/2012/03/mysql-backup-and-partia...
Обсуждается: http://www.opennet.dev/tips/info/2679.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по ответам | RSS]

1. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от anonymous (??) on 04-Апр-12, 17:28 

Хрень какая.
IndoDB (в подавляещем случае на продакшене он) так не восстановить.
Про копирование больших объемов данных через ssh вообще помолчу.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от anonymous (??) on 04-Апр-12, 17:28 
*InnoDB
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от IceMan (ok) on 04-Апр-12, 19:17 
А аргументы какие? Или не пробовал, но уверен что работать не будет?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от Аноним (??) on 07-Апр-12, 19:24 
а LVM здесь в каком месте используется? Их снепшоты могут бэкапить базу данных? Хотя бы в простое?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от IceMan (ok) on 08-Апр-12, 00:59 
LVM тут упомянут как один из способов создать консистентный бэкап mysql без остановки сервера. По ссылке внизу поста есть пример как это сделать. Хотя оно не суть важно. Описанный способ позволять сделать частичное восстановление данных из "сырых файлов" баз. Не важно каким образом они были созданы LVM снапшот или остановка сервера. Главное чтобы они были в консистентном состоянии.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от Онаним on 09-Апр-12, 13:06 
>Главное чтобы они были в консистентном состоянии.

То-то и оно. Только вот как с помощью LVM получить консистентную копию базы работающего мускула, у которого кеш размером с ОП?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от IceMan (ok) on 09-Апр-12, 16:42 
А причем тут размер кеша? По-моему вы напрочь не понимаете что такое кеш и что такое исменения в буфере, которые еще не записаны на диск. FLUSH TABLES WITH READ LOCK записывает все изменения на диск и предотвращает последующие изменения.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от Аноним (??) on 09-Апр-12, 20:39 
Innodb, после пропадания питания, а lvm снапшот симулирует эту ситуацию, начинает активно читать и писать, если находилось под нагрузкой, для того чтобы применить лог транзакций с последнего чекпойта.

Как результат, sshfs+aufs могут дать возможность запустить mysqldump только через несколько суток.

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

Так же дамп/востановление с помощью mysqldump на базах в 50-300GB может быть очень медленным даже на хорошем железе 2-4 часа. Всё это время сеть скорее всего будет в полке, как следствие будет потеря пакетов и проблемы у клиентов базы данных.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от Аноним (??) on 09-Апр-12, 20:42 
>>Главное чтобы они были в консистентном состоянии.
> То-то и оно. Только вот как с помощью LVM получить консистентную копию
> базы работающего мускула, у которого кеш размером с ОП?

InnoDB позволяет востанавливать базу в случае пропадания питания.
Все данные на которые прошёл COMMIT не будут потеряны в не зависимости от размера кеша innodb в памяти (buffer pool), работает и на 100MB кеше и на 100GB, везде.

Если файловая система правильная и не нарушает порядок записи блоков когда послан fsync, то LVM снапшот диска позволяет делать "холодный" бекап.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от Аноним (??) on 09-Апр-12, 20:44 
> А причем тут размер кеша? По-моему вы напрочь не понимаете что такое
> кеш и что такое исменения в буфере, которые еще не записаны
> на диск. FLUSH TABLES WITH READ LOCK записывает все изменения на
> диск и предотвращает последующие изменения.

Даже без этой команды всё будет хорошо, если вся база в InnoDB.

Если она в myisam, значит вас совершенно не интересует сохранность этих данных и можно бекапить, а потом делать repair table на все myisam таблицы

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

13. "Частичное восстановление данных MySQL из бэкапа, созданного ..."  +/
Сообщение от mahoro (??) on 28-Апр-12, 15:01 
Использование MyISAM не говорит о том, что данные не важны.

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру