а выгоды нет вообще никакой... какого то кратного увеличения производительности тупо не наблюдается на больших масштабах
в том числе и в PostgreSQL ;)
Авито тоже на 13й постгрес не переедет я думаю =)

Ну в новых версиях появляются и новые фичи, они когда-нибудь могут стать нужны

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

всем доброе утро
а есть тут в чате те, кто имеет опыт восстановления репликации для случая когда есть триггеры на 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 начнут триггеры срабатывать...

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

Коллеги, есть у кого RBGPOE на продажу одна штука?

Ээ, онож в account сыпет, если сделать что-то типо "system,!account" то отрубит вообще все логи об авторизации, или я не прав? :)

Всегда нужно пробовать что-то новое :)

Для этого и существуют DBA  :)

Помнится от Мишы у нас стоял такой отборный мат в такие моменты. Относительно быстро выпилили все триггеры из баз 🙂

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

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

только если новое ожидаемо лучше работает
очевидно что толпа разрозненных API
хуже чем унифицированный SNMP

ээээ... я бы сказал так что у вас вообще какое то очень странное представление о работе DBA ;)

DBA физически не в состоянии ЗАСТАВИТЬ перейти на новую версию
ну только если в старой во что-то такое уперлись, что просто пипец мешает жить
ну типа как MySQL4 без транзакций и row lock "недобаза"
а MySQL5 уже что-то похожее на СУБД...

ну вот как то так и сделал в итоге

ну это mysqldump да,.. но повезло что нагрузки на master нет
и что это staging ...

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

Я про программистов не знающих старые фичи :)

Ну и DBA - в смысле архитект а не админ :)

дак архитектор или DBA?

DBA - это Data Base Administrtor - OPS для баз данных.