wsrep_gtid_domain_id=1111 на трёх нодах одинаковый

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

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

может всё же стоит server_id=1 на всех узлах галеры прописать?

коллеги, никто не знает обходных маневров для вот такой ситуации?
https://jira.percona.com/browse/PXB-2132?jql=text%20~%20%22schema%20mismatch%22

нашел ответы на свои вопросы в официальной доке. и накатал скрипт для ускорения процесса:

position=$(cat xtrabackup_binlog_info | awk 'NR==1 {print $3}')
mysql -u root -ptest -e "SET GLOBAL gtid_slave_pos=\"${position}\";"

даже при использовании GTID нужно указывать координаты, они лежат в бэкапе в файле xtrabackup_binlog_info

Чат переехал @JavaLovesYou

всем доброе утро
а есть тут в чате те, кто имеет опыт восстановления репликации для случая когда есть триггеры на SLAVE?

binlog_format=MIXED

есть таблица prod.session2, при репликации с мастера на slave на таблицу навешаны триггеры, которые добавляют данные в bimereports и REPORTING
на slave залили dump без master data напрямую в prod.session2
с DROP TABLE \ CREATE TABLE + CREATE TRIGGER (в конце дампа)

в результате
имеем
SHOW SLAVE STATUS

     Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table: mysql.%,REPORTING.%,bimereports.%
                  Last_Errno: 1062
                  Last_Error: Could not execute Write_rows event on table prod.session2; Duplicate entry '3677293' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000096, end_log_pos 66185900


не понимаю как теперь сделать так чтобы восстановить репликацию?
не потеряв данные которые есть на slave в REPORTING и в bimereports

думал в сторону pt-table-sync
но оно с триггерами не работает

сделать mysqldump —master-data только для выбранной таблицы? но вроде тоже не поможет, при попытке залить такой дамп на slave начнут триггеры срабатывать...

=( схему с триггерами городил не я, помогите люди добрые а?

дропнуть триггеры, востановить. Либо через pt-table-checksum / pt-table-sync

pt-table-sync как видит триггеры говорит "сдаюсь"

--nocheck-triggers если эти триггеры ничего не меняют

меняют =) в том то и беда
триггеры при вставке в таблицу заполняют другие таблицы =)

по идее надо как то "временно триггеры выключить"
видимо придется убивать триггеры
потом через SQL_SLAVE_SKIP_COUNTER пропустить репликацию...
потом на MASTER
залить дамп
DROP TABLE  / CREATE TABLE ... + CREATE TRIGGERS
в конце

блин повезло что это staging а не продакшен и нагрузки на таблицу нет....

а черт... надо CREATE TRIGGERS из дампа убить..

коллеги подскажите если в вакансии требует это , то как лучше спрашивать/готовиться ?
настраивать репликации и понимаете их отличия друг от друга (master-slave, master-master, multi-master), GTID;
внедряли ProxySQL/HaProxy/MaxScale/Vitess;

@naimson как минимум поставить dbdeployer, потыкать палочкой в запущенное на виртуалках/контейнерах. Настройка не такая тяжёлая штука, как понимание ограничений: FK, DDL, конфликты блокировок в горячих строках. В балансировщиках: как сделать неравномерную нагрузку и как с этим бороться. Спрашивают или что вы делали сами или просят настроить в EC2, как сломать репликации и как потом починить.

Ну как? Поставить у себя и попробовать. Лучше вручную.

ну с EC2 я там не думаю что стоит просить

вот вам ssh на 4 ec2 инстанса, вот скрипт на пайтоне который лезет в базу по доменному имени из /etc/hosts. Проведите миграцию из одиночного инстанса в реплику/кластер с минимальным даунтаймом.

2 часа, мы тут рядом посидим.

а там внутри по-желанию таблички без PK, myisam...