Задавайте вопросы, мы ответим
Вы не зашли.
Подскажите по репликации.
master1 - MariaDB-server-10.1.17-1.el6
master2 - MariaDB-server-10.1.17-1.el7.centos
Имеем репликацию master-master. Второй мастер остановил репликацию без видимых причин. Ощущение, что не переварил бинлог в 81 гибов.
### master 1
Неактивен
А что в show processlist? Там, небось, применяющий поток работает. Единственное, что смущает, — это отставание на ноль, но оно может обновиться после того, как доработает тот запрос, который 81 гиг бинлога сделал.
Неактивен
Утомил меня конечно mysql в данном кейсе. Вообщем на слейве таки появилась ошибка. Какая уж точно не скажу. Наверное 1236 или еще какая .
Вообщем решил проблему тем, что упаковал бинлоги, скопировал на слейв и там залил в базу. По другому никак не получилось. Даже pt-slave-restart завис с не понятной ерундой в strace.
Но вот опять сегодня делал load data на одном из серверов и опять поймал на слейве
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mariadb-bin.000033' at 1748701184, the last event read from 'mariadb-bin.000033' at 1748701184, the last byte read from 'mariadb-bin.000033' at 1748701203.'
� а � то раз бинлог � ов� ем не большой, в� его 11Gb.
При этом разные буфера вроде как выкручены на оптимальные значени� на обоих � ерверах (master-master)
max_allowed_packet 1073741824
slave_max_allowed_packet 1073741824
net_buffer_length 1048576
max_binlog_size 1073741824
binlog_format STATEMENT
Будут какие-то предложени� по � табильной репликации?
Мен� например видит� � такой вариант.
1. вы� тавить бинарные логи например в 900 Мб
2. Дробить файл data перез зиливкой например на 950 Мб - больше чем размер бинарного лога, но меньше чем max_allowed_packet.
То е� ть таким образом mysql закроет лог на размере в 950 Мб.
3. Может перейти на формат бинлогов типа mixed?
P.S. � колько пишу � ообщени� , � только мучаю� ь � кракоз� брами. � игде у мен� такой проблемы нет.
Отредактированно sv (03.10.2016 16:29:03)
Неактивен
Про кракозябры — очень странно, в какой кодировке пишете? Ну то есть у меня все буквы работают
Про заливку:
1. max_allowed_packet бывает триггерится, когда реально большой объем данных. В этом случае нужно просто убедиться, что размеры пакетов на обоих серверах стоят одинаковые. Но иногда он триггерится, когда побился бинлог (или позиция), тогда в качестве размера воспринимается неправильное число, и в таком случае хорошего способа нет, надо изучать, почему произошел сбой и переливать.
2. Про размеры — зачем вам такие огромные размеры на max_allowed_packet? Мне кажется, что даже дебиановские 16 мегабайт по умолчанию, — очень много. Аналогичный вопрос про max_binlog_size. Поставьте какие-то разумные значения (например, начните со значений по умолчанию).
Неактивен
� у � мотрите. У мен� е� ть база объемом 2,2TiB.
В ней около 300 таблиц. Каждый день добавл� ет� � нова� табличка объемом примерно 10-20 Gb.
Е� ть два � ервера. � а� троена msater-master репликаци� . Специфика в том, что � базу никто не пишет кроме мен� . Только читают.
� епликаци� работает отвратительно. Это � в� зано � тем, что � ервера географиче� ки разне� ены друг от друга.
Столкнувши� ь � ошибкой max_allowed_packet � нашел рекомендации
set max_allowed_packet to 1G on both Master and Slave
set net_buffer_length to its max value of 1M on both Master and Slave
http://dba.stackexchange.com/questions/ … -change-it
По поводу кракоз� бр. По� тавьте opensuse 13.2 в виртуалку и напишите � ообщение на форуме. У мен� проблем нигде нет только тут.
Неактивен
Я бы усомнился в правильности такого решения. В конце концов, если бы такое ограничение не было нужно, то его бы не делали. Как минимум, если при передаче данных что-то пойдет не так, перекачивать гигабайт дольше, чем, скажем, 4 мегабайта. Применительно к запросам, это делает запросы размером менее 4 мегабайт, и это тоже хорошо, иначе вы не будете ловить странности ORM, когда они пытаются перезаписать половину базы каким-нибудь хитрым WHERE. Я бы рекомендовал поднимать значения тогда, когда это нужно, а не просто убирать ограничения.
Неактивен
Тестирую кракозябры. Простите за спам. Это сообщение отправлено из ОпенСусе 13.2.
UPD: Форум работает. Может, в браузере какая-то проблема? Я поставил сусе с настройками по умолчанию (там почему-то по умолчанию КДЕ), и в настройках КДЕ прописал переключение на русский язык.
Неактивен
paulus написал:
Я бы у� омнил� � в правильно� ти такого решени� . В конце концов, е� ли бы такое ограничение не было нужно, то его бы не делали. Как минимум, е� ли при передаче данных что-то пойдет не так, перекачивать гигабайт дольше, чем, � кажем, 4 мегабайта. Применительно к запро� ам, � то делает запро� ы размером менее 4 мегабайт, и � то тоже хорошо, иначе вы не будете ловить � транно� ти ORM, когда они пытают� � перезапи� ать половину базы каким-нибудь хитрым WHERE. Я бы рекомендовал поднимать значени� тогда, когда � то нужно, а не про� то убирать ограничени� .
То е� ть е� ли канал между двух � ерверов тупит, то лучше � тавить max_allowed_packet ближе к минимальному значению?
То е� ть е� ли у на� пишет� � бинлог в не� колько де� � тков гибов, то он в� е равно читать� � � лейвом будет чанками такими какой размер указан в данной опции?
У мен� xfce 4.10. Браузеры Chrome Version 53.0.2785.116 (64-bit)
и FF 48.0.1. В обоих така� проблема. Linux без ру� ификаторов. � а� тройки вроде как по дефолту. Еще и � ообщени� режен к� тати. � адо нажать об� зательно кнопку Preview (и уже по� ле � того видны кракоз� бры) перед Submit. К� тати кракоз� бр на англий� ком нет. Видно дей� твительно что-то � кодировкой.Вот у мен� така� . Вроде как ничего криминального.
bash-4.2$ locale
LANG=en_US.utf8
LC_CTYPE=en_US.utf8
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
Отредактированно sv (04.10.2016 11:33:54)
Неактивен
Еще один тест сообщения из сусе под xfce. Кажется, что всё работает.
Неактивен
Да, разбивка на файлы — это всего лишь разбивка на файлы. Данные внутри все равно распределяются как-то. Бывают запросы, которые начинаются в одном файле и заканчиваются в другом, и тут нет никакой проблемы.
https://ru.opensuse.org/Xfce — вот тут написано, что xfce может неправильно отображать символы, если установлен пакет gtk-qt-engine. После его удаления нужно выполнить SuSEconfig --modul gtk2.
Неактивен
У мен� такой пакет не у� тановлен.
По поводу транзакций. В данном � лучае у мен� е� ть LOAD DATA, который в новую таблицу загружает пор� дка 10 Gb. При � том получают� � � оответ� вующие логи. То е� ть LOAD DATA не размазывает данные по бинарным файлам у котрых размер задан в 1Gb. То е� ть когда � лейв читает � тот огромный бинарный лог, то рвет репликацию. Вот � егодг� заргузил табличку размером 12,7 Gb.
Слейв прочел только
3.3G SQL_LOAD-2-1-33.data
Он вначале � оздает data файл в темпомом каталого, а потом выполн� ет LOAD DATA.
Отредактированно sv (04.10.2016 16:13:38)
Неактивен
Уже пару ме� � цев заливает� � инфа по принципу опи� анному мной выше - дамп дробит� � на мелкие файлы, каждый из которых меньше размера бинарного лога. В итоге в� е работает � табильно и репликаци� не отваливает� � .
Отредактированно sv (08.12.2016 20:37:59)
Неактивен