Исправление manul91, (текущая версия) :
ЕМНИП я делал statement based репликацию, не знаю, лучший ли это вариант, но у меня проблем не было.
Statement-based можно только если есть абсолютная уверенность, что изменения в базе всегда абсолютно детерминированы (не зависят от внешнего мира/окружения, crypto, random, всяких там датах и т.д.).
Вам наверное, повезло; это может привести к необнаруживаемым ошибкам и неконсистентностей
Например (второй случай), если приложение выкатывает такую последовательность на мастере:
insert into author author.id=uuid(), …..
{select last-insert-id … берет последний primary key для автора какой получился, пусть id=‘blah-blah-87AZ..’)
insert into article …., author.id = ‘blah-blah-87AZ..’
…
… на слейве при statement-репликации такое либо не пройдет, либо данные вообще откатятся и запись будет отсутствовать (если в трансакции, и innodb с foreign key constraint) т.к. для author.id слейв у себя сгенерит другой uuid.
С датами еще хуже
Исправление manul91, :
ЕМНИП я делал statement based репликацию, не знаю, лучший ли это вариант, но у меня проблем не было.
Statement-based можно только если есть абсолютная уверенность, что изменения в базе всегда абсолютно детерминированы (не зависят от внешнего мира/окружения, crypto, всяких там датах и т.д.).
Вам наверное, повезло; это может привести к необнаруживаемым ошибкам и неконсистентностей
Например (второй случай), если приложение выкатывает такую последовательность на мастере:
insert into author author.id=uuid(), …..
{select last-insert-id … берет последний primary key для автора какой получился, пусть id=‘blah-blah-87AZ..’)
insert into article …., author.id = ‘blah-blah-87AZ..’
…
… на слейве при statement-репликации такое либо не пройдет, либо данные вообще откатятся и запись будет отсутствовать (если в трансакции, и innodb с foreign key constraint) т.к. для author.id слейв у себя сгенерит другой uuid.
С датами еще хуже
Исходная версия manul91, :
ЕМНИП я делал statement based репликацию, не знаю, лучший ли это вариант, но у меня проблем не было. Statement-based можно только если есть абсолютная уверенность, что изменения в базе всегда абсолютно детерминированы (не зависят от внешнего мира/окружения, crypto, всяких там датах и т.д.).
Вам наверное, повезло; это может привести к необнаруживаемым ошибкам и неконсистентностей
Например (второй случай), если приложение выкатывает такую последовательность на мастере:
insert into author author.id=uuid(), …..
{select last-insert-id … берет последний primary key для автора какой получился, пусть id=‘blah-blah-87AZ..’)
insert into article …., author.id = ‘blah-blah-87AZ..’
…
… на слейве при statement-репликации такое либо не пройдет, либо данные вообще откатятся и запись будет отсутствовать (если в трансакции, и innodb с foreign key constraint) т.к. для author.id слейв у себя сгенерит другой uuid.
С датами еще хуже