Привет.

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

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

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

--
Regards,
Oleg

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

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

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

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
>>
>
>

А дальше как? Останавливать слейв, делать копию спула?

Я тут попробовал с 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

> нужно не только 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
>>
>
>

Заврешать процесс не нужно. Действительно, достаточно 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

Кстати, пробовал
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

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

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/

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.

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

Можно использовать 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.
>
> Перегружаю базу ооочень редко. Поэтому останавливать ее ради одного бэкапа
> я бы не советовал.
>

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/

Криво вставилась последняя ссылка в прошлом письме:
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 и слейвы, но помнить что базы могут разойтись и если
> это критично - думать о других вариантах.
>
>

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? Как по мне - проверять _нужно_.

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

По теме - лвм снепшоты пока жуткое говно и падение на записи будет раза
в два. На солярке дешево и вкусно использовать ZFS снепы. На линуксе же
наверное таки стоит 5.5 и слейвы, но помнить что базы могут разойтись и
если это критично - думать о других вариантах.

А почему базы могут расходиться?
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 и слейвы, но помнить что базы могут разойтись и
> если это критично - думать о других вариантах.
>

Привет.

Именно так я и пробовал, разве что логин и пароль передавал через конфиг.
Вот только 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.

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

К предыдущему письму.
Для ускорения выключения 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

как бы производительность не упала после такого тюнинга...

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

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/

Проверять идентичность репликации можно как советуют через
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? Как по мне - проверять _нужно_.
>

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? Как по мне - проверять _нужно_.
>>
>
>

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, хочу на выходных
потестить.

> Замечание по поводу проверки идентичности данных - справедливое. У нас
> простое самописное решение - в таблицу записыватеся значение и через
> указанный интервал времени проверяется, есть ли оно на слэйве. Если
> нет - шлется алерт.
>
> А можно подробней о возможности не проверять идентичность master-slave
> на 5.1 и 5.5? Как по мне - проверять _нужно_.
>
Имелась в виду возможность включить row based replication в 5.1+, что
значительно уменьшает вероятность фейла репликации. Проверять удобно с
помощью мааткит, я использую немного модифицированную версию для своих
нужд.

On 05/22/2011 08:53 AM, Александр Кобыченко wrote:
>
> А почему базы могут расходиться?
>
1) в 5.0 или меньше - передавать запрос было не очень хорошим решением,
куча запросов даст разный результат на разных серверах (особенно если у
нас есть rand() или now() в инсерте).
2) Глюк юзерленд софта (случайно записали в слейв, например, рекомендую
ставить глобальное read only = yes)
3) Глюк репликации (не б-ги горшки обжигают, например). Почитайте
чендждлоги к мисклу 5.1, grep -i repl
4) Креш мискла слейва или сервера при репликации тоже может к этом
привести.

Такие дела.

On 05/23/11 12:43 PM, Alex Samorukov wrote:
> 2) Так в принципе работает асинхронная репликация. Мастер отдал слейву
> евент. слейв его принял. В этот момент если слейв упадет - данные еще
> есть только в кеше ОС. Так что не стоит этому слишком доверять. Для 99%
> случаев бекап слейва - это ок, но если у вас, например, банковские
> транзакции или подобные задачи - то явно нет.
А в каком это банке мускулом пользуются?

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 и весьма немаленький. Какой - не скажу, да и
неважно.