R
Size: a a a
2020 July 16
В
Кто может рассказать что делает под капотом
Я столкнулся с тем, что, когда снимал дамп со слейва, у меня появилась транзакция
mysqldump, если он запущен с параметром --lock-all-tables?Я столкнулся с тем, что, когда снимал дамп со слейва, у меня появилась транзакция
Errant GTID с командой FLUSH TABLES:mysqlbinlog mysql-bin.000001 | grep -C 10 '7678bb24-c757-11ea-9790-080027f645a4'
...
SET @@SESSION.GTID_NEXT= '7678bb24-c757-11ea-9790-080027f645a4:1'/*!*/;
# at 67108
#200716 13:41:22 server id 3 end_log_pos 67186 CRC32 0x6cfb734f Query thread_id=2526 exec_time=0 error_code=0
SET TIMESTAMP=1594906882/*!*/;
SET @@session.sql_mode=0/*!*/;
FLUSH TABLES
/*!*/;
...NI
general log всё расскажет
В
general log всё расскажет
Почему появилась
Errant GTID? Как этого избежать?
NI
что такое: https://www.percona.com/live/19/sites/default/files/slides/Errant%20GTIDs%20Breaking%20Replication_%20How%20to%20Detect%20and%20Avoid%20Them%20-%20FileId%20-%20187306.pdf
надо поглядеть какой запрос на слейве вызвал такую проблему (найти что за транзакция в бинлоге слейва выполнилась локально)
надо поглядеть какой запрос на слейве вызвал такую проблему (найти что за транзакция в бинлоге слейва выполнилась локально)
В
Кто может рассказать что делает под капотом
Я столкнулся с тем, что, когда снимал дамп со слейва, у меня появилась транзакция
mysqldump, если он запущен с параметром --lock-all-tables?Я столкнулся с тем, что, когда снимал дамп со слейва, у меня появилась транзакция
Errant GTID с командой FLUSH TABLES:mysqlbinlog mysql-bin.000001 | grep -C 10 '7678bb24-c757-11ea-9790-080027f645a4'
...
SET @@SESSION.GTID_NEXT= '7678bb24-c757-11ea-9790-080027f645a4:1'/*!*/;
# at 67108
#200716 13:41:22 server id 3 end_log_pos 67186 CRC32 0x6cfb734f Query thread_id=2526 exec_time=0 error_code=0
SET TIMESTAMP=1594906882/*!*/;
SET @@session.sql_mode=0/*!*/;
FLUSH TABLES
/*!*/;
...так вот эта транзакция ☝️
7678bb24-c757-11ea-9790-080027f645a4:1
В
Кто может рассказать что делает под капотом
Я столкнулся с тем, что, когда снимал дамп со слейва, у меня появилась транзакция
mysqldump, если он запущен с параметром --lock-all-tables?Я столкнулся с тем, что, когда снимал дамп со слейва, у меня появилась транзакция
Errant GTID с командой FLUSH TABLES:mysqlbinlog mysql-bin.000001 | grep -C 10 '7678bb24-c757-11ea-9790-080027f645a4'
...
SET @@SESSION.GTID_NEXT= '7678bb24-c757-11ea-9790-080027f645a4:1'/*!*/;
# at 67108
#200716 13:41:22 server id 3 end_log_pos 67186 CRC32 0x6cfb734f Query thread_id=2526 exec_time=0 error_code=0
SET TIMESTAMP=1594906882/*!*/;
SET @@session.sql_mode=0/*!*/;
FLUSH TABLES
/*!*/;
...Я понял в чем причина!
mysqldump запущен под root
Параметр
mysqldump запущен под root
Параметр
--lock-all-tables добавляет какой-то запрос на слейве и эта транзакция в бинлоге слейва выполняется локально.В
а здесь mysqldump запускался от
backup_user
CREATE USER 'backup_user'@'10.0.0.0/255.255.255.0' IDENTIFIED WITH mysql_native_password BY 'password';и у него тупо не хватило привелегий создать запрос, который вызвал бы
GRANT USAGE, SELECT, SHOW VIEW, LOCK TABLES, RELOAD, REPLICATION CLIENT, EVENT, TRIGGER ON *.* TO 'backup_user'@'10.0.0.0/255.255.255.0';
GRANT REPLICATION_SLAVE_ADMIN ON *.* TO 'backup_user'@'10.0.0.0/255.255.255.0';
Errant GTIDВ
что такое: https://www.percona.com/live/19/sites/default/files/slides/Errant%20GTIDs%20Breaking%20Replication_%20How%20to%20Detect%20and%20Avoid%20Them%20-%20FileId%20-%20187306.pdf
надо поглядеть какой запрос на слейве вызвал такую проблему (найти что за транзакция в бинлоге слейва выполнилась локально)
надо поглядеть какой запрос на слейве вызвал такую проблему (найти что за транзакция в бинлоге слейва выполнилась локально)
А как правильно посмотреть запрос по номеру GTID?
Например:
Например:
7678bb24-c757-11ea-9790-080027f645a4:1NI
там в pdf строчка была, я поэтому и скинул, через mysqlbinlog
2020 July 17
ПА
Подкажите в хранимой процедуре получается если я обозначу IN переменную как @ myVar (без пробела т.к. бот ругается, т.е. с использованием @ - собаки) то она везде равна NULL, или ее вызывать как то по особенному надо?
СШ
Подкажите в хранимой процедуре получается если я обозначу IN переменную как @ myVar (без пробела т.к. бот ругается, т.е. с использованием @ - собаки) то она везде равна NULL, или ее вызывать как то по особенному надо?
Почему не нулл должна быть?
ПА
Ну я создаю процедуру, объявляю ей IN входные значения, так вот, если значения я назову начиная с @ тогда она будет NULL не важно, что я ей значение передал, если @ убираю, то все норм.
Это именно так во входящих значениях
Это именно так во входящих значениях
ПА
Почему не нулл должна быть?
Потому, что это IN параметр и я в него передаю значение