В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

ru_mysql

739 membersпожаловаться на группу
2020 July 10

MP

Maksim Petuhov in ru_mysql
Mb1W@
А сама таблица r_group как выглядит на обоих серверах?
да, кстати, структуру таблиц не сравнивал
это хорошая мысль, но она по идее не должна измениться
по крайней мере это должно быть последовательно
источник
15:07пожаловаться#1

M

Mb1W@ in ru_mysql
Обратите внимание на значение автоинкремента.
источник
15:08пожаловаться#2

M

Mb1W@ in ru_mysql
Может что-то коллеги подскажут.
Может кто-то с подобным в Марии сталкивался...
источник
15:09пожаловаться#3

MP

Maksim Petuhov in ru_mysql
Mb1W@
Обратите внимание на значение автоинкремента.
структура идентична, а вот автоинкремент отличается т.к. на данный момент реплика отстает от мастера и предсказуемо на мастере значение больше чем на слейве
источник
15:13пожаловаться#4

MP

Maksim Petuhov in ru_mysql
Mb1W@
Может что-то коллеги подскажут.
Может кто-то с подобным в Марии сталкивался...
спасибо большое за участие
источник
15:13пожаловаться#5

M

Mb1W@ in ru_mysql
Maksim Petuhov
спасибо большое за участие
Не за что. Я бы откатил слейв на ту же версию, что и на мастере.
Сделал бы новый дамп и начал бы с этого.
источник
15:14пожаловаться#6

MP

Maksim Petuhov in ru_mysql
уже предложил этот вариант, но пока не получил ответа
источник
15:16пожаловаться#7

MP

Maksim Petuhov in ru_mysql
Mb1W@
Не за что. Я бы откатил слейв на ту же версию, что и на мастере.
Сделал бы новый дамп и начал бы с этого.
уже предложил этот вариант, но пока не получил ответа
также думаю сделать reset на slave и для верности drop-нуть БД на slave перед заливкой, хотя в дампе он уже есть
источник
15:17пожаловаться#8

MP

Maksim Petuhov in ru_mysql
Mb1W@
Не за что. Я бы откатил слейв на ту же версию, что и на мастере.
Сделал бы новый дамп и начал бы с этого.
думал более опытные коллеги подскажут варианты

и поделятся опытом что может ломать реплику дублями
источник
15:18пожаловаться#9

MP

Maksim Petuhov in ru_mysql
как будет время попробую поднять на тестовом стенде master-slave и помоделировать ситуации с дублями, но как всегда на это нужно время, которое в дефиците
источник
15:19пожаловаться#10

MN

Max N. in ru_mysql
Всем привет, подскажите по уровню изоляции READ UNCOMMITTED. Почему при запуске читающей транзакции с уровнем изоляции READ UNCOMMITTED у InnoDB начинает расти история (History list length)? Насколько я понимаю - все запросы в рамках этой транзакции не будут лезть в undo лог, будут просто с индекса считывать даже возможно незакомиченные изменения...
источник
15:21пожаловаться#11

MN

Max N. in ru_mysql
Получается сам select будет читать из индекса данные без использования undo. Но почему в процессе этого селекта история начинает копиться, непонятно кому она нужна)
источник
15:33пожаловаться#12

NI

Nickolay Ihalainen in ru_mysql
Max N.
Всем привет, подскажите по уровню изоляции READ UNCOMMITTED. Почему при запуске читающей транзакции с уровнем изоляции READ UNCOMMITTED у InnoDB начинает расти история (History list length)? Насколько я понимаю - все запросы в рамках этой транзакции не будут лезть в undo лог, будут просто с индекса считывать даже возможно незакомиченные изменения...
undo всё равно нужен для корректного crash recovery, даже если нет никаких параллельных транзакций.
источник
15:33пожаловаться#13

EG

Evgeny Grinevich in ru_mysql
Всем привет.  Вопрос есть практический, кончилось место на разделе где живет мускул innodb. И он не дает оптимизировать таблицы чтобы место освободить. Если дропнуть таблицу, при свободном месте на диске 0 это получится? И тут же ее пересоздать.
Какой вообще выход из такой ситуации простой может быть?
источник
15:57пожаловаться#14

A

Alexander in ru_mysql
перенести таблицы на другой диск.
источник
15:58пожаловаться#15

M

Mb1W@ in ru_mysql
Посмотреть какие из логов вы можете временно уменьшить.
Возможно вам этого места хватит.
Еще можно посмотреть что кроме мускуля живет на диске и возможно что-то перенести из этого.
источник
16:01пожаловаться#16

EG

Evgeny Grinevich in ru_mysql
кроме мускуля ничего нет. логи там 90мб весят. думаю они моментально после старта забьются
источник
16:02пожаловаться#17

MN

Max N. in ru_mysql
Если есть еще диски можно перекинуть пару таблиц используя Transportable Tablespaces (ток там есть свои условия, смотреть над подходит или нет)
источник
16:10пожаловаться#18

NI

Nickolay Ihalainen in ru_mysql
90mb хватит, чтобы truncate сделать
источник
16:17пожаловаться#19

EG

Evgeny Grinevich in ru_mysql
спасибо за варианты, почитаю как перекинуть таблицы, это в каких то условиях может быть реально выходом.
А сейчас рискнул дропнул таблицу с логами, нормально дропнулась при 0 свободного места и пересоздал
источник
16:17пожаловаться#20