История изменений

ЕМНИП я делал 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.

С датами еще хуже

ЕМНИП я делал 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.

С датами еще хуже

ЕМНИП я делал 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.

С датами еще хуже