но маркетинг ...

интересно) А в целом если использовать GTID - есть ли преумщество в скорости репликации?

нет

в скорости преимуществ нет. GTID делает более удобным перепозиционирование и снижает человеческий фактор

всё точно так же, как и раньше

но добавляет сильно больше гемороя при починке слетевшей репликации

понятно) Спасибо)

и еще один вопрос: при настройке репликации без GTID как вы получаете сообщения об ошибках репликации?

мониторинг

по факту sql thread running: no

ну а дальше уже от мониторинга зависит, умный - ещё и строчку ошибки приведёт, глупый - заставит в error.log посмотреть или в show slave status

вот хит сезона в плане мониторинга: https://pmmdemo.percona.com/graph/dashboard/db/mysql-replication?orgId=1

можно скачать бесплатно, без регистрации и смс!

:D

А есть скрипт которые будет отсылать mail при ошибке у кого-то, а лучше если интеграция со слаком была?)

таких скриптов наверняка много, но я не DBA, не пользуюсь

вот тут пишут, что в PMM тоже есть, включая слак: https://www.percona.com/blog/2017/01/23/mysql-and-mongodb-alerting-with-pmm-and-grafana/

вот тут пишут, что в PMM тоже есть, включая слак: https://www.percona.com/blog/2017/01/23/mysql-and-mongodb-alerting-with-pmm-and-grafana/

там целый прометей

он может слать куда угодно

и графана - которая тоже может алертить

у нас прометей шлет в телеграм

ага. я так понимаю, в PMM на самом деле графановский alerting используется

вообще, я бы сейчас просто ставил прометей, мускул_экспортеры на клиенты

а в прометее просто ставил бы дашборды от перконы

единственный минус, что такой аналитики по запросам не будет

просто этот пмм немного черный ящик

я бы даже сказал чОрный контейнер :) но да, тут Перкона упирает на установку "в пару кликов" и всё вот это

ну, скажу честно, когда я ставил это в первый раз, не зная толком докер и прометей стек - я был в восторге

надо кстати учитывать что вот этот пмм 1) много пишет 2) прометей не предназначен для длительного хранения метрик

там полоток емнип 3 месяца

и еще - построение графика на большом таймфрейме не слабо обвалит вам сервер

С gtid можно заставить slave проигрывать репликацию в несколько потоков

в скорости преимуществ нет. GTID делает более удобным перепозиционирование и снижает человеческий фактор

Так что если нагрузка большая, то выйгрыш определенно будет

есть одно но

иногда проебывается autoposition

и приходится плясать с бубном - иногда переливать репликацию

и сделать skip транзакции там посложнее

Хм, юзаем мастер-мастер на gtid, пока никакой попоболи не испытывали

С gtid можно заставить slave проигрывать репликацию в несколько потоков

а без gtid нельзя что ли?

а без gtid нельзя что ли?

можно

Хм, юзаем мастер-мастер на gtid, пока никакой попоболи не испытывали

еще скажите что в оба пишите

В оба в оба

день переставал быть томным

хорошо у вас в 4м измерении

и как боретесь с тем, что у вас больше нету эйсида?

и как боретесь с тем, что у вас больше нету эйсида?

эйсид хуейсид

у меня есть geo-растянутый кластер master-master из 4х машин

пишут на все узлы

не вижу ничего страшного в гео

стоит обычная file/pos

но писать в оба мастера, это такое

писать в 4 - ваще огонь

а без gtid нельзя что ли?

Можно, но тогда задачи резервного копирования немного усложняются

нормально там всё. offset-ы ...

это чем это они усложняются?

нормально там всё. offset-ы ...

а проверяли?

а то у меня тоже было норм

а count по таблицам разный

проверяли через pt-table-check

эйсид хуейсид

ну, в принципе жить можно

ну и код тоже гонял данные, сверял

это чем это они усложняются?

конфликтами

ну, я подозреваю что на несложном дизайне бд, наверное можно

какими конфликтами?

ну, я подозреваю что на несложном дизайне бд, наверное можно

если там append-only, то жить можно

если там append-only, то жить можно

ну да

и одна таблица

и две колонки )

какими конфликтами?

С одного мастера ты снял x = 1, с другого x = 2. Где верное значение?

ну да

только зачем для этого весь этот геморрой с мускулом - хз

Пошла жара )

etki - если они в синке, то значения будут одинаковые

лол

а если у тебя offset не стоит, то ссзб

а) ты не можешь сделать синхронный коммит в распределенной системе. физически. б) когда у тебя снимается дамп, ты опять же не можешь гарантировать, что у тебя будут видны данные из одного и того же момента времени

Удваиваю этого господина

single-transaction - ы?

если про mysqldump

я не знаю, что это такое, но оно не спасет от физики

man mysqldump, возможно, это - ответ на твои опасения

лол

я с интересом выслушаю - интересно, какие грабли могут быть

Смотри, я посылаю запрос UPDATE huge_table SET x = 2 на какой-то мастер. Он пересылает это на другой мастер. Пока этот запрос не завершился с успехом, как мне быть уверенным, что два одновременных запроса на получение данных либо увидят эти изменения, либо не увидят?

transaction isolation level

у тебя асинхронная репликация

да не работает же

на первом мастере применилось, на втором еще нет

или наоборот, в зависимости от протокола

ну и увидит на втором старое значение

в чём проблема-то?

в том, что ты снимешь два разных дампа

нет

что никакого эйсида и уровней изоляции уже не существует

я сниму дамп на момент времени X

и данные в нём будут консистентны

datediff() прекрасно работает с типом date, поэтому нет смысла в timestamp()

огромное спасибо

через проблему, что данные в уже сдампленной таблице поменялись во время дампа другой таблицы и у них есть связь через ВК, я уже проходил фиг знает сколько лет назад