|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго дня, Коллеги!
Ситуация у меня следующая - есть одна табличка в БД (mysql 5.7), которую я хочу со временем реплицировать на другой сервер (именно эту табличку).
Именно поэтому не хочу делать id автоинкрементным, думаю сделать guid или что-то такое.
Стал смотреть в сторону функции uuid()
, прочел в документации
UUID() does not work with statement-based replication.
По ссылке
http://mechanics.flite.com/blog/2014/12 … -in-mysql/
описан механизм, который предписывает делать вот так:
master > set @uuid = uuid(); Query OK, 0 rows affected (0.00 sec) master > insert into uuid_test (binlog_format,uuid_string) values(@@binlog_format,@uuid); Query OK, 1 row affected, 1 warning (0.00 sec)
update по той же схеме.
Возникает вопрос - а в чем разница-то? Ведь значение одно и то же пишется.
Почему необходимо запускать функцию uuid() именно на мастере и что будет, если запускать на слейве?
И второе - не налетал ли кто на подводные камни при использовании такой схемы?
Поделитесь, у кого был опыт пожалуйста.
Неактивен
Если выполнить функцию на слейве, то получится другой uuid. Это недетерменистическая функция, поэтому для statement-based репликации не подходит.
Неактивен
Благодарствую )
Неактивен
deadka написал:
И второе - не налетал ли кто на подводные камни при использовании такой схемы?
дока рекомендует (гарантия качества)
https://dev.mysql.com/doc/refman/5.6/en … tions.html
дока написал:
As a workaround for the preceding limitations when statement-based replication is in effect, you can use the strategy of saving the problematic function result in a user variable and referring to the variable in a later statement. For example, the following single-row INSERT is problematic due to the reference to the UUID() function:
INSERT INTO t VALUES(UUID());
To work around the problem, do this instead:
SET @my_uuid = UUID();
INSERT INTO t VALUES(@my_uuid);
That sequence of statements replicates because the value of @my_uuid is stored in the binary log as a user-variable event prior to the INSERT statement and is available for use in the INSERT.
The same idea applies to multiple-row inserts, but is more cumbersome to use....
Неактивен
Ну доке верить надо. )
Отпишу, если будет что-то нештатное.
Неактивен
vasya написал:
deadka написал:
И второе - не налетал ли кто на подводные камни при использовании такой схемы?
дока рекомендует (гарантия качества)
https://dev.mysql.com/doc/refman/5.6/en … tions.htmlдока написал:
As a workaround for the preceding limitations when statement-based replication is in effect, you can use the strategy of saving the problematic function result in a user variable and referring to the variable in a later statement. For example, the following single-row INSERT is problematic due to the reference to the UUID() function:
INSERT INTO t VALUES(UUID());
To work around the problem, do this instead:
SET @my_uuid = UUID();
INSERT INTO t VALUES(@my_uuid);
That sequence of statements replicates because the value of @my_uuid is stored in the binary log as a user-variable event prior to the INSERT statement and is available for use in the INSERT.
The same idea applies to multiple-row inserts, but is more cumbersome to use....
Ну кстати изящное решение. Я ведь правильно понял, что при statement-based репликации, в отличие от запросов, которые пишутся как есть, переменные перед попаданием в лог вычисляются?
Отредактированно Shopen (15.03.2018 01:18:36)
Неактивен
Судя по https://dev.mysql.com/doc/refman/5.6/en … gging.html
A statement to be logged might contain references to user-defined variables. To handle this, MySQL writes a SET statement to the binary log to make sure that the variable exists on the slave with the same value as on the master. For example, if a statement refers to a variable @my_var, that statement will be preceded in the binary log by the following statement, where value is the value of @my_var on the master:
SET @my_var = value;
сам INSERT, использующий переменную, останется неизменным. Но перед ним в логе будет SET, содержащий константное значение @my_uuid, чтобы гарантировать существование на слейве переменной с тем же именем и значением.
Неактивен
А касательного самого типа репликации? Ограничения, в контексте которых тред и начался - они касаются statement-based. В случае mixed-реплакации мы, получается, также должны учитывать это ограничение на uuid() (и только в случае row-based репликации можем ""расслабиться)?
Неактивен
В случае mixed-реплакации тоже можем расслабиться, она как раз и предназначена для обработки таких случаев: если можем пишем в лог statement, в случае неоднозначности - row.
Теоретически mixed берет лучшее от statement и row. Но, почему-то, по дефолту mixed стоял только в 5.1 (потом вернули statement, сейчас row).
Неактивен
Мм, так все же, получается, нужно "читерить" с set @uuid = uuid();
в случае mixed-репликации? Раз уж она "по умолчанию" использует statement?
Неактивен
нет, не нужно
у mixed-репликации смешанный лог (в нем и statement, и row вперемешку)
везде где возможно используется statement, но недетерминированные запросы (например, с uuid()) запишет в виде row
Неактивен
Спасибо большое!
Неактивен
