Welcome! Log In Create A New Profile

Advanced

Как лучше бэкапить MySQL

Posted by Oleg Motienko 
Oleg Motienko
Как лучше бэкапить MySQL
May 20, 2011 09:04PM
Привет.

Очень хочется уйти от mysqldump, так как объемы базы уже перевалили 100гиг.
Поэтому ищем другие способы.
Естественно, первым делом попробовали Percona XtraBackup. Как по мануалу,
запускаем скрипт innobackupex.
На активной базе данных копия сливается за час, вроде бы всё нормально. А
вот после пытаемся запустить apply log, и скопированная база оказывается
нерабочей. Исторически сложилось, что innodb_file_per_table не используется
и данные лежат одним файлом.

В чем может быть проблема?

Какие еще варианты? Навскидку - LVM snapshot, что еще?

--
Regards,
Oleg
Evgeny P
Re: Как лучше бэкапить MySQL
May 21, 2011 03:14AM
Держать слейв или пару слейвов не вариант?

21 мая 2011 г. 1:59 пользователь Oleg Motienko <motienko@gmail.com> написал:

> Привет.
>
> Очень хочется уйти от mysqldump, так как объемы базы уже перевалили 100гиг.
> Поэтому ищем другие способы.
> Естественно, первым делом попробовали Percona XtraBackup. Как по мануалу,
> запускаем скрипт innobackupex.
> На активной базе данных копия сливается за час, вроде бы всё нормально. А
> вот после пытаемся запустить apply log, и скопированная база оказывается
> нерабочей. Исторически сложилось, что innodb_file_per_table не используется
> и данные лежат одним файлом.
>
> В чем может быть проблема?
>
> Какие еще варианты? Навскидку - LVM snapshot, что еще?
>
> --
> Regards,
> Oleg
>
Really Big Bug
Re: Как лучше бэкапить MySQL
May 21, 2011 03:46AM
xtrabackup (пользуюсь им + свои скрипты) вроде как официально неработает без
perfile. perfile даёт большое преимущество для "ужимания" файла бд (можно
соптимизировать отдельные таблицы, а не только все базы). так что может
стоит сдампить и залить со включенным perfile, может и размер базы ужмётся в
3-4 раза :)

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

ну и mysqldump для 100 гиговой базы это вообще антивариант ;(

С lvm снепшотами у меня не сложилось, а вот с zfs заработало классно.

2011/5/21 Evgeny P <qwertydzen@gmail.com>

> Держать слейв или пару слейвов не вариант?
>
> 21 мая 2011 г. 1:59 пользователь Oleg Motienko <motienko@gmail.com>написал:
>
>> Привет.
>>
>> Очень хочется уйти от mysqldump, так как объемы базы уже перевалили
>> 100гиг. Поэтому ищем другие способы.
>> Естественно, первым делом попробовали Percona XtraBackup. Как по мануалу,
>> запускаем скрипт innobackupex.
>> На активной базе данных копия сливается за час, вроде бы всё нормально. А
>> вот после пытаемся запустить apply log, и скопированная база оказывается
>> нерабочей. Исторически сложилось, что innodb_file_per_table не используется
>> и данные лежат одним файлом.
>>
>> В чем может быть проблема?
>>
>> Какие еще варианты? Навскидку - LVM snapshot, что еще?
>>
>> --
>> Regards,
>> Oleg
>>
>
>
Oleg Motienko
Re: Как лучше бэкапить MySQL
May 21, 2011 03:48AM
А дальше как? Останавливать слейв, делать копию спула?

Я тут попробовал с LVM немного, вроде бы получается.
Делаем так:
mysql> FLUSH TABLES;
/bin/sync
lvcreate -s -n mysqlsnap blablabla (делаем snapshot).
mount -r /dev/mapper/mysqlsnap /blabla
дальше делаем rsync на бэкапную машину.
ну и
umount
lvremove

Пробовал, на бэкапной машине успешно стартует база, правда, InnoDB довольно
долго фиксит там что-то.

Вот только как узнать, насколько актуальной и "не битой" получается такая
база?

2011/5/21 Evgeny P <qwertydzen@gmail.com>

> Держать слейв или пару слейвов не вариант?
>
>
>

--
Regards,
Oleg
Really Big Bug
Re: Как лучше бэкапить MySQL
May 21, 2011 03:52AM
> нужно не только flush tables, но и lock tables. А ещё лучше вообще процесс
> mysqld завершить на этот момент.
>
>
> 2011/5/21 Oleg Motienko <motienko@gmail.com>
>
>> А дальше как? Останавливать слейв, делать копию спула?
>>
>> Я тут попробовал с LVM немного, вроде бы получается.
>> Делаем так:
>> mysql> FLUSH TABLES;
>> /bin/sync
>> lvcreate -s -n mysqlsnap blablabla (делаем snapshot).
>> mount -r /dev/mapper/mysqlsnap /blabla
>> дальше делаем rsync на бэкапную машину.
>> ну и
>> umount
>> lvremove
>>
>> Пробовал, на бэкапной машине успешно стартует база, правда, InnoDB
>> довольно долго фиксит там что-то.
>>
>> Вот только как узнать, насколько актуальной и "не битой" получается такая
>> база?
>>
>> 2011/5/21 Evgeny P <qwertydzen@gmail.com>
>>
>>> Держать слейв или пару слейвов не вариант?
>>>
>>>
>>>
>>
>> --
>> Regards,
>> Oleg
>>
>
>
Dmitry Menshikov
Re: Как лучше бэкапить MySQL
May 21, 2011 04:44AM
Заврешать процесс не нужно. Действительно, достаточно FLUSH TABLES WITH READ
LOCK. Ну и анлокнуть потом не забыть)

21 мая 2011 г. 10:50 пользователь Really Big Bug <bigbug@mafia.lv> написал:

>
> нужно не только flush tables, но и lock tables. А ещё лучше вообще процесс
>> mysqld завершить на этот момент.
>>
>>
>> 2011/5/21 Oleg Motienko <motienko@gmail.com>
>>
>>> А дальше как? Останавливать слейв, делать копию спула?
>>>
>>> Я тут попробовал с LVM немного, вроде бы получается.
>>> Делаем так:
>>> mysql> FLUSH TABLES;
>>> /bin/sync
>>> lvcreate -s -n mysqlsnap blablabla (делаем snapshot).
>>> mount -r /dev/mapper/mysqlsnap /blabla
>>> дальше делаем rsync на бэкапную машину.
>>> ну и
>>> umount
>>> lvremove
>>>
>>> Пробовал, на бэкапной машине успешно стартует база, правда, InnoDB
>>> довольно долго фиксит там что-то.
>>>
>>> Вот только как узнать, насколько актуальной и "не битой" получается такая
>>> база?
>>>
>>> 2011/5/21 Evgeny P <qwertydzen@gmail.com>
>>>
>>>> Держать слейв или пару слейвов не вариант?
>>>>
>>>>
>>>>
>>>
>>> --
>>> Regards,
>>> Oleg
>>>
>>
>>
>


--
Yours truly, Dmitry Menshikov
http://menshikov.mp
Oleg Motienko
Re: Как лучше бэкапить MySQL
May 21, 2011 04:56AM
Кстати, пробовал
FLUSH TABLES WITH READ LOCK
Подождал часа два, но он так и висел в состоянии Waiting to get readlock

На эту тему нашел
http://bugs.mysql.com/bug.php?id=54673

P.S. База круглосуточно активна по чтению и записи: update и insert .

2011/5/21 Dmitry Menshikov <d.menshikov@gmail.com>
>
> Заврешать процесс не нужно. Действительно, достаточно FLUSH TABLES WITH READ LOCK. Ну и анлокнуть потом не забыть)
>
> 21 мая 2011 г. 10:50 пользователь Really Big Bug <bigbug@mafia.lv> написал:
>>
>>> нужно не только flush tables, но и lock tables. А ещё лучше вообще процесс mysqld завершить на этот момент.
>>>


--
Regards,
Oleg
Dmitry Menshikov
Re: Как лучше бэкапить MySQL
May 21, 2011 10:32AM
Pushed into mysql-5.5 5.5.9


21 мая 2011 г. 11:49 пользователь Oleg Motienko <motienko@gmail.com>написал:

> Кстати, пробовал
> FLUSH TABLES WITH READ LOCK
> Подождал часа два, но он так и висел в состоянии Waiting to get readlock
>
> На эту тему нашел
> http://bugs.mysql.com/bug.php?id=54673
>
> P.S. База круглосуточно активна по чтению и записи: update и insert .
>
> 2011/5/21 Dmitry Menshikov <d.menshikov@gmail.com>
> >
> > Заврешать процесс не нужно. Действительно, достаточно FLUSH TABLES WITH
> READ LOCK. Ну и анлокнуть потом не забыть)
> >
> > 21 мая 2011 г. 10:50 пользователь Really Big Bug <bigbug@mafia.lv>
> написал:
> >>
> >>> нужно не только flush tables, но и lock tables. А ещё лучше вообще
> процесс mysqld завершить на этот момент.
> >>>
>
>
> --
> Regards,
> Oleg
>



--
Yours truly, Dmitry Menshikov
http://menshikov.mp
Sergey Kobzar
Re: Как лучше бэкапить MySQL
May 21, 2011 10:32AM
On 05/21/11 11:49, Oleg Motienko wrote:

> Кстати, пробовал
> FLUSH TABLES WITH READ LOCK
> Подождал часа два, но он так и висел в состоянии Waiting to get readlock
>
> На эту тему нашел
> http://bugs.mysql.com/bug.php?id=54673
>
> P.S. База круглосуточно активна по чтению и записи: update и insert .
>
> 2011/5/21 Dmitry Menshikov<d.menshikov@gmail.com>
>>
>> Заврешать процесс не нужно. Действительно, достаточно FLUSH TABLES WITH READ LOCK. Ну и анлокнуть потом не забыть)
>>
>> 21 мая 2011 г. 10:50 пользователь Really Big Bug<bigbug@mafia.lv> написал:
>>>
>>>> нужно не только flush tables, но и lock tables. А ещё лучше вообще процесс mysqld завершить на этот момент.

У меня база >200G. Использую LVM snapshot для бэкапа. Снэпшот делаю
shell скриптом вот так:
mysql --user=$MYSQL_USER --password=$MYSQL_PASS << EOF
FLUSH TABLES WITH READ LOCK;
system sync;
system /sbin/lvcreate --snapshot --name $SNAP --size $SNAP_SIZE
/dev/${VG}/${LV};
UNLOCK TABLES;
EOF


Да, бэкап лучше запускать на слэйве, т.к. во время копирования 200G
сервер становится useless. Можно конечно IO шедулером поиграться, но я
решил проблему в лоб. В указанный промежуток времени распараллеливание
запросов между мастером с лэйвом отключается и спользуетсся только
мастер, а на слэйве копируются базы.

Вот еще статья по теме ничего: http://habrahabr.ru/blogs/personal/102738/
Sergey Kobzar
Re: Как лучше бэкапить MySQL
May 21, 2011 10:32AM
On 05/21/11 10:50, Really Big Bug wrote:

> нужно не только flush tables, но и lock tables. А ещё лучше вообще
> процесс mysqld завершить на этот момент.

Вы пробовали завершить остановить/запустить процесс для базы >100G? :).

У меня с innodb_buffer_pool_size = 34G:
- стопается >10 min
- выход на рабочую мощность после рестарта происходит минимум минут за
15-20.

Перегружаю базу ооочень редко. Поэтому останавливать ее ради одного
бэкапа я бы не советовал.
Vitaliy Okulov
Re: Как лучше бэкапить MySQL
May 21, 2011 02:30PM
Можно использовать LVM, для linux есть скрипт mylvmbackup, который
оптимизирует данный процесс.
Минус тут только 1 - во время backup сильно падает производительность СУБД
как из-за 2-го чтения, так и из-за особенностей LVM.

Можно использовать xtrabackup.
Можно использовать аппаратные снапшоты, если поддерживает контроллер.

По поводу сервера, с которого делать backup при использовании репликации, то
для 5.0 лучше использовать master, так как slave очень часто бывает не
идентичен, и его нужно всегда проверять при помощи maatkit.
Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
идентичности slave сервера, но только при использовании бинарной репликации.

21 мая 2011 г. 15:38 пользователь Sergey Kobzar <sergey.kobzar@mail.ru>написал:

> On 05/21/11 10:50, Really Big Bug wrote:
>
> нужно не только flush tables, но и lock tables. А ещё лучше вообще
>> процесс mysqld завершить на этот момент.
>>
>
> Вы пробовали завершить остановить/запустить процесс для базы >100G? :).
>
> У меня с innodb_buffer_pool_size = 34G:
> - стопается >10 min
> - выход на рабочую мощность после рестарта происходит минимум минут за
> 15-20.
>
> Перегружаю базу ооочень редко. Поэтому останавливать ее ради одного бэкапа
> я бы не советовал.
>
Vitaliy Okulov
Re: Как лучше бэкапить MySQL
May 21, 2011 06:36PM
22 мая 2011 г. 1:20 пользователь Alex Samorukov <samm@os2.kiev.ua> написал:

> On 05/21/2011 08:28 PM, Vitaliy Okulov wrote:
>
>>
>> Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
>> идентичности slave сервера, но только при использовании бинарной репликации.
>>
> Это не так, если вам конечно ценны ваши данные.
>

В этом моменте поподробнее можно? Были ли случаи расхождения данных? С чем
они были связаны?
У меня на 5.0 были, причем не раз.


>
> По теме - лвм снепшоты пока жуткое говно и падение на записи будет раза в
> два. На солярке дешево и вкусно использовать ZFS снепы. На линуксе же
> наверное таки стоит 5.5 и слейвы, но помнить что базы могут разойтись и если
> это критично - думать о других вариантах.
>
>
Согласен, падение примерно раза в 2-3.
Кстати, в Linux кто-нибудь использует ZFS?
Для примера есть 2-а интересных проекта: http://zfsonlinux.org/ и
http://zfsonlinux.org/
Vitaliy Okulov
Re: Как лучше бэкапить MySQL
May 21, 2011 06:38PM
Криво вставилась последняя ссылка в прошлом письме:
https://github.com/zfs-linux/zfs

22 мая 2011 г. 1:20 пользователь Alex Samorukov <samm@os2.kiev.ua> написал:

> On 05/21/2011 08:28 PM, Vitaliy Okulov wrote:
>
>>
>> Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
>> идентичности slave сервера, но только при использовании бинарной репликации.
>>
> Это не так, если вам конечно ценны ваши данные.
>
> По теме - лвм снепшоты пока жуткое говно и падение на записи будет раза в
> два. На солярке дешево и вкусно использовать ZFS снепы. На линуксе же
> наверное таки стоит 5.5 и слейвы, но помнить что базы могут разойтись и если
> это критично - думать о других вариантах.
>
>
Sergey Kobzar
Re: Как лучше бэкапить MySQL
May 22, 2011 02:38AM
On 05/21/11 21:28, Vitaliy Okulov wrote:
> Можно использовать LVM, для linux есть скрипт mylvmbackup, который
> оптимизирует данный процесс.
> Минус тут только 1 - во время backup сильно падает производительность
> СУБД как из-за 2-го чтения, так и из-за особенностей LVM.
>
> Можно использовать xtrabackup.
> Можно использовать аппаратные снапшоты, если поддерживает контроллер.
>
> По поводу сервера, с которого делать backup при использовании
> репликации, то для 5.0 лучше использовать master, так как slave очень
> часто бывает не идентичен, и его нужно всегда проверять при помощи maatkit.
> Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
> идентичности slave сервера, но только при использовании бинарной репликации.

Замечание по поводу проверки идентичности данных - справедливое. У нас
простое самописное решение - в таблицу записыватеся значение и через
указанный интервал времени проверяется, есть ли оно на слэйве. Если нет
- шлется алерт.

А можно подробней о возможности не проверять идентичность master-slave
на 5.1 и 5.5? Как по мне - проверять _нужно_.
Alex Samorukov
Re: Как лучше бэкапить MySQL
May 22, 2011 02:38AM
On 05/21/2011 08:28 PM, Vitaliy Okulov wrote:
>
> Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
> идентичности slave сервера, но только при использовании бинарной
> репликации.
Это не так, если вам конечно ценны ваши данные.

По теме - лвм снепшоты пока жуткое говно и падение на записи будет раза
в два. На солярке дешево и вкусно использовать ZFS снепы. На линуксе же
наверное таки стоит 5.5 и слейвы, но помнить что базы могут разойтись и
если это критично - думать о других вариантах.
Александр Кобыченко
Re: Как лучше бэкапить MySQL
May 22, 2011 02:56AM
А почему базы могут расходиться?
22.05.2011 10:37 пользователь "Alex Samorukov" <samm@os2.kiev.ua> написал:
> On 05/21/2011 08:28 PM, Vitaliy Okulov wrote:
>>
>> Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
>> идентичности slave сервера, но только при использовании бинарной
>> репликации.
> Это не так, если вам конечно ценны ваши данные.
>
> По теме - лвм снепшоты пока жуткое говно и падение на записи будет раза
> в два. На солярке дешево и вкусно использовать ZFS снепы. На линуксе же
> наверное таки стоит 5.5 и слейвы, но помнить что базы могут разойтись и
> если это критично - думать о других вариантах.
>
Oleg Motienko
Re: Как лучше бэкапить MySQL
May 22, 2011 03:32AM
Привет.

Именно так я и пробовал, разве что логин и пароль передавал через конфиг.
Вот только with read lock не отработало, так как в базе постоянно идут
апдейты.

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

По поводу InnoDB - у меня выключается минут 6-7, включается около 12.

----------
From: *Sergey Kobzar* <sergey.kobzar@mail.ru>
Date: 2011/5/21
To: highload-php-ru@googlegroups.com


У меня база >200G. Использую LVM snapshot для бэкапа. Снэпшот делаю shell
скриптом вот так:
mysql --user=$MYSQL_USER --password=$MYSQL_PASS << EOF
FLUSH TABLES WITH READ LOCK;
system sync;
system /sbin/lvcreate --snapshot --name $SNAP --size $SNAP_SIZE
/dev/${VG}/${LV};
UNLOCK TABLES;
EOF


Да, бэкап лучше запускать на слэйве, т.к. во время копирования 200G сервер
становится useless. Можно конечно IO шедулером поиграться, но я решил
проблему в лоб. В указанный промежуток времени распараллеливание запросов
между мастером с лэйвом отключается и спользуетсся только мастер, а на
слэйве копируются базы.

Вот еще статья по теме ничего: http://habrahabr.ru/blogs/personal/102738/

----------
From: *Sergey Kobzar* <sergey.kobzar@mail.ru>
Date: 2011/5/21
To: highload-php-ru@googlegroups.com


Вы пробовали завершить остановить/запустить процесс для базы >100G? :).

У меня с innodb_buffer_pool_size = 34G:
- стопается >10 min
- выход на рабочую мощность после рестарта происходит минимум минут за
15-20.

Перегружаю базу ооочень редко. Поэтому останавливать ее ради одного бэкапа я
бы не советовал.
Oleg Motienko
Re: Как лучше бэкапить MySQL
May 22, 2011 04:36AM
К предыдущему письму.
Для ускорения выключения InnoDB советуют
set global *innodb*_*max*_*dirty*_*pages*_*pct* = 0;

http://www.mysqlperformanceblog.com/2009/04/15/how-to-decrease-innodb-shutdown-times/

2011/5/22 Oleg Motienko <motienko@gmail.com>

>
> По поводу InnoDB - у меня выключается минут 6-7, включается около 12.
>
>


--
Regards,
Oleg
Dmitry Menshikov
Re: Как лучше бэкапить MySQL
May 22, 2011 05:34AM
как бы производительность не упала после такого тюнинга...

22 мая 2011 г. 11:32 пользователь Oleg Motienko <motienko@gmail.com>написал:

> К предыдущему письму.
> Для ускорения выключения InnoDB советуют
> set global *innodb*_*max*_*dirty*_*pages*_*pct* = 0;
>
>
> http://www.mysqlperformanceblog.com/2009/04/15/how-to-decrease-innodb-shutdown-times/
>
> 2011/5/22 Oleg Motienko <motienko@gmail.com>
>
>>
>> По поводу InnoDB - у меня выключается минут 6-7, включается около 12.
>>
>>
>
>
> --
> Regards,
> Oleg
>



--
Yours truly, Dmitry Menshikov
http://menshikov.mp
Alex Vorona
Re: Как лучше бэкапить MySQL
May 22, 2011 06:04AM
22.05.2011 12:24, Dmitry Menshikov wrote:
> как бы производительность не упала после такого тюнинга...
Перед shutdown делать и ждать пока dirty pages пропишутся на диск - тогда и делать shutdown.
> 22 мая 2011 г. 11:32 пользователь Oleg Motienko <motienko@gmail.com>написал:
>
>> К предыдущему письму.
>> Для ускорения выключения InnoDB советуют
>> set global *innodb*_*max*_*dirty*_*pages*_*pct* = 0;
>>
>>
>> http://www.mysqlperformanceblog.com/2009/04/15/how-to-decrease-innodb-shutdown-times/
Evgeny P
Re: Как лучше бэкапить MySQL
May 22, 2011 08:40AM
Проверять идентичность репликации можно как советуют через
http://www.maatkit.org/
http://www.maatkit.org/Хотя я сам не пробовал.

21 мая 2011 г. 22:39 пользователь Sergey Kobzar <sergey.kobzar@mail.ru>написал:

> On 05/21/11 21:28, Vitaliy Okulov wrote:
>
>> По поводу сервера, с которого делать backup при использовании
>> репликации, то для 5.0 лучше использовать master, так как slave очень
>> часто бывает не идентичен, и его нужно всегда проверять при помощи
>> maatkit.
>> Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
>> идентичности slave сервера, но только при использовании бинарной
>> репликации.
>>
>
> Замечание по поводу проверки идентичности данных - справедливое. У нас
> простое самописное решение - в таблицу записыватеся значение и через
> указанный интервал времени проверяется, есть ли оно на слэйве. Если нет -
> шлется алерт.
>
> А можно подробней о возможности не проверять идентичность master-slave на
> 5.1 и 5.5? Как по мне - проверять _нужно_.
>
Vitaliy Okulov
Re: Как лучше бэкапить MySQL
May 22, 2011 01:52PM
Maatkit на 5.0 я использовал, для проверки нужны 2-е утилиты:
mk-table-checksum и mk-table-sync.
На базах в 400-500 Gb проверка проходит часов 4-5, за несколько лет данные
утилиты реально помогли найти 5-6 рассинхронизацией между master - slave
серверами. Некоторые проблемы возникали из-за разработчиков, то есть
использовались запросы, которые на master и slave давали разные результаты,
какие именно запросы были - сейчас не вспомню уже, часть проблем была
связана с отказами самого mysql в случае если кончилось место на диске или
еще что-нибудь.

Сергей, по поводу вашего метода проверки - мне кажется нужно проверять
реальные данные, а не тот факт, что данные просто проходят репликацию. Для
этого достаточно мониторит вывод show slave status.

Александр, базы в 5.0 могут расходиться из-за того, что один и тотже запрос
на master и slave серверах может выдать разные результаты. Более подробно
прочитайте 3 и 4 блоки в посте:
http://www.xaprb.com/blog/2007/01/20/how-to-make-mysql-replication-reliable/

22 мая 2011 г. 16:30 пользователь Evgeny P <qwertydzen@gmail.com> написал:

> Проверять идентичность репликации можно как советуют через
> http://www.maatkit.org/
> http://www.maatkit.org/Хотя я сам не пробовал.
>
> 21 мая 2011 г. 22:39 пользователь Sergey Kobzar <sergey.kobzar@mail.ru>написал:
>
>> On 05/21/11 21:28, Vitaliy Okulov wrote:
>>
>>> По поводу сервера, с которого делать backup при использовании
>>> репликации, то для 5.0 лучше использовать master, так как slave очень
>>> часто бывает не идентичен, и его нужно всегда проверять при помощи
>>> maatkit.
>>> Для 5.1 и 5.5 по идее можно не использовать инструментарий проверки
>>> идентичности slave сервера, но только при использовании бинарной
>>> репликации.
>>>
>>
>> Замечание по поводу проверки идентичности данных - справедливое. У нас
>> простое самописное решение - в таблицу записыватеся значение и через
>> указанный интервал времени проверяется, есть ли оно на слэйве. Если нет -
>> шлется алерт.
>>
>> А можно подробней о возможности не проверять идентичность master-slave на
>> 5.1 и 5.5? Как по мне - проверять _нужно_.
>>
>
>
Alex Samorukov
Re: Как лучше бэкапить MySQL
May 23, 2011 04:52AM
On 05/22/2011 12:35 AM, Vitaliy Okulov wrote:
>
>
> 22 мая 2011 г. 1:20 пользователь Alex Samorukov <samm@os2.kiev.ua
> <mailto:samm@os2.kiev.ua>> написал:
>
> On 05/21/2011 08:28 PM, Vitaliy Okulov wrote:
>
>
> Для 5.1 и 5.5 по идее можно не использовать инструментарий
> проверки идентичности slave сервера, но только при
> использовании бинарной репликации.
>
> Это не так, если вам конечно ценны ваши данные.
>
>
> В этом моменте поподробнее можно? Были ли случаи расхождения данных? С
> чем они были связаны?
> У меня на 5.0 были, причем не раз.
Да и несколько раз.

1) Когда row replication появился в нем было много багов. На некоторые я
и наступал и честно их репортил. Репликация прерывалась по несколько раз
в день! Сейчас все пофиксили вроде, но как и раньше - никаких гарантий.
2) Так в принципе работает асинхронная репликация. Мастер отдал слейву
евент. слейв его принял. В этот момент если слейв упадет - данные еще
есть только в кеше ОС. Так что не стоит этому слишком доверять. Для 99%
случаев бекап слейва - это ок, но если у вас, например, банковские
транзакции или подобные задачи - то явно нет.
3) Еще одно решение - забабло правда, R1 backup. Там ставится кернельный
модуль и идет бекап блочного девайса. У нас 1 из клиентов использует,
правда скорость vs native не мерял, но он достаточно загружен и вроде
все ок.
>
> По теме - лвм снепшоты пока жуткое говно и падение на записи будет
> раза в два. На солярке дешево и вкусно использовать ZFS снепы. На
> линуксе же наверное таки стоит 5.5 и слейвы, но помнить что базы
> могут разойтись и если это критично - думать о других вариантах.
>
>
> Согласен, падение примерно раза в 2-3.
Кстати, на последнем линукстаге была конференция о снепшотах в ЛВМ. Их
сейчас полностью переписывают и обещают скорость сравнимую с
конкурентами (падение до 10%). Пока все только в git, хочу на выходных
потестить.
Alex Samorukov
Re: Как лучше бэкапить MySQL
May 23, 2011 04:54AM
> Замечание по поводу проверки идентичности данных - справедливое. У нас
> простое самописное решение - в таблицу записыватеся значение и через
> указанный интервал времени проверяется, есть ли оно на слэйве. Если
> нет - шлется алерт.
>
> А можно подробней о возможности не проверять идентичность master-slave
> на 5.1 и 5.5? Как по мне - проверять _нужно_.
>
Имелась в виду возможность включить row based replication в 5.1+, что
значительно уменьшает вероятность фейла репликации. Проверять удобно с
помощью мааткит, я использую немного модифицированную версию для своих
нужд.
Alex Samorukov
Re: Как лучше бэкапить MySQL
May 23, 2011 04:54AM
On 05/22/2011 08:53 AM, Александр Кобыченко wrote:
>
> А почему базы могут расходиться?
>
1) в 5.0 или меньше - передавать запрос было не очень хорошим решением,
куча запросов даст разный результат на разных серверах (особенно если у
нас есть rand() или now() в инсерте).
2) Глюк юзерленд софта (случайно записали в слейв, например, рекомендую
ставить глобальное read only = yes)
3) Глюк репликации (не б-ги горшки обжигают, например). Почитайте
чендждлоги к мисклу 5.1, grep -i repl
4) Креш мискла слейва или сервера при репликации тоже может к этом
привести.

Такие дела.
Andrey N. Oktyabrski
Re: Как лучше бэкапить MySQL
May 24, 2011 03:36PM
On 05/23/11 12:43 PM, Alex Samorukov wrote:
> 2) Так в принципе работает асинхронная репликация. Мастер отдал слейву
> евент. слейв его принял. В этот момент если слейв упадет - данные еще
> есть только в кеше ОС. Так что не стоит этому слишком доверять. Для 99%
> случаев бекап слейва - это ок, но если у вас, например, банковские
> транзакции или подобные задачи - то явно нет.
А в каком это банке мускулом пользуются?
Alex Samorukov
Re: Как лучше бэкапить MySQL
May 25, 2011 03:12AM
On 05/24/2011 09:35 PM, Andrey N. Oktyabrski wrote:
> On 05/23/11 12:43 PM, Alex Samorukov wrote:
>> 2) Так в принципе работает асинхронная репликация. Мастер отдал слейву
>> евент. слейв его принял. В этот момент если слейв упадет - данные еще
>> есть только в кеше ОС. Так что не стоит этому слишком доверять. Для 99%
>> случаев бекап слейва - это ок, но если у вас, например, банковские
>> транзакции или подобные задачи - то явно нет.
> А в каком это банке мускулом пользуются?
>
Банковские транзакции могут быть не только в банке. В рассматриваем
случае был payment gateway и весьма немаленький. Какой - не скажу, да и
неважно.
Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 61
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready