⚡ Сверхбыстрый COMMIT — повод проверить, переживут ли данные сбой. Если приложение уже ...
⚡ Сверхбыстрый COMMIT — повод проверить, переживут ли данные сбой. Если приложение уже показало, что заказ оформлен, после аварии запись все равно может исчезнуть. При синхронной фиксации PostgreSQL ждет сохранения WAL на энергонезависимом носителе. Просто передать данные в кэш ОС недостаточно: при потере питания они пропадут. Если убрать ожидание записи, задержка COMMIT сократится, а число транзакций в секунду вырастет. Но вместе со скоростью изменятся гарантии сохранности. Здесь важно различать два параметра: 1️⃣ fsync = off отключает принудительную синхронизацию записи. Сбой ОС или оборудования грозит потерей данных и повреждением базы. 2️⃣ synchronous_commit = off разрешает отвечать клиенту до сохранения WAL. Последние транзакции могут потеряться, но этот режим сам по себе не нарушает согласованность базы. 🔎 Как проверить результат бенчмарка: ✅ Измерьте задержку COMMIT с одним клиентом. Так проще увидеть вклад ожидания записи. ✅ Проверьте синхронизацию WAL. Сопоставьте настройки, системные вызовы и активность хранилища. Одна метрика еще ничего не доказывает. ✅ Проведите аварийный тест на отдельном стенде. После жесткой перезагрузки проверьте сохранность подтвержденных изменений и целостность базы. Низкая задержка сама по себе не доказывает проблему. Но при выборе СУБД к цифрам производительности стоит добавить проверку: что останется от подтвержденных транзакций после аварии? 🔗 Читайте на Хабре, как проверить, переживут ли данные аварийный сбой.
Канал в каталоге Максиметера
590 подписчиков · IT и технологии