Репликация по DDIA: что я понял, только когда сам сломал прод

[gerbert_MX]

нейротекст по заметкам?

[tojiboyevumidjon]

типа исползовал ли я ИИ для написание статьи? Только правки граматики так как русскый не мой родной язык

[AivanF]

Статья в целом интересная, но правда очень сильно ЧатомГопотой отдаёт, и в структуре, и во всех формулировках…

[tojiboyevumidjon]

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

[gerbert_MX]

лучше https://languagetool.org/ru и его производные используйте чем ИИ как редактор

исправление ошибок это одно, но ИИ любит "исправлять" переписывая все в ноль превращая в нейротекст

[tojiboyevumidjon]

оооо пасибо большое

[Granulex]

Переход на одного мастера решает конфликты записи, но создаёт другую версию той же проблемы: при асинхронной репликации запись может быть подтверждена клиенту, но ещё не попасть на реплику. Если мастер падает в этот момент – реплика становится новым мастером с данными, о которых клиент думает, что они сохранены. DDIA называет это «иллюзией сохранности» и разбирает в той же главе 5. Синхронная репликация убирает иллюзию, но за счёт скорости ответа.

[tojiboyevumidjon]

Ну да я в статье эту сторону обошёл. В моём случае "мастер" это вся внешняя БД (SAP B1 или Smartup), её внутренняя durability и failover уже не моя зона на это интеграционный слой не влияет. Но проблема которую вы описали у меня всё равно вылезает этажом выше. Воркер может отправить запись, получить 200 упасть до того как у себя зафиксировал отправлено, и при следующем запуске отправить заново. Не потеря, но дубль в финансах разница тоже неприятная.

Это закрывают idempotency keys плюс часовая метрика расхождения. Полностью убрать "иллюзию" можно только синхронной репликацией или quorum ом, но для enterprise-интеграций такой ценой обычно не платят. Если бы речь шла про реальный платёжный шлюз пошёл бы туда не задумываясь.