Ответ: тип numeric позволяет хранить и индексировать числа со 131 072 десятичными цифрами до точки. Для больших чисел придется отыскать или сделать расширение.

Ответ: ESB — это зачастую сервер приложений, API которого может подстраиваться под целевые системы и преобразовывать данные между форматами разных систем. Реализация такого в Postgres видится не вполне целесообразной.

Ответ: вся инсталляция нативна, без бинарной транасляция, то есть чистый e2k. Потенциал производительности – да, теряем, но для этого существуют доработанные, т.е. не ванильные, версии PostgreSQL.

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

Ответ: Tantor Polar, как и PostgreSQL, для обеспечения долговечности данных вызывает сброс буферов на диск через аналог fsync() — в API PolarFS это pfsd_fsync() (и соответствующий вызов в libpfs). Без реальной реализации этого вызова нельзя гарантировать, что после сбоя питания или падения узла записанные данные действительно окажутся на постоянном носителе.

В оригинальной открытой реализации PolarFS вызовы pfsd_fsync() и pfs_fsync() были пустыми операциями (noop): они ничего не делали. Причины в коде не задокументированы. Возможные объяснения - в облачной версии PolarFS поверх PolarStore запись могла считаться «автоматически устойчивой» (например, семантика вроде O_SYNC на уровне хранилища). Для блочного устройства (бэкенд PFS_DEV_DISK), которое мы используем, это не применимо. Или же разработчики могли считать, что раз PolarFS использует только небуферизованный I/O (O_DIRECT), явный fsync() не нужен.

На деле O_DIRECT лишь обходит кэш страниц ОС и гарантирует попадание данных в кэш устройства, а не обязательно на энергонезависимый носитель. Считать запись устойчивой можно только если железо гарантирует защиту от потери питания (PLP), а в общем случае — и тем более в программно-определяемом хранилище — полагаться на это нельзя.

Поэтому в нашей доработанной PolarFS исправлено: при вызове pfsd_fsync() / pfs_fsync() теперь принудительно выполняется сброс кэша записи нижележащего блочного устройства (аналог flush на уровне диска). Поведение включается опцией конфигурации diskdev_flush_enable (по умолчанию включено). Это даёт Tantor Polar корректную гарантию долговечности при использовании PolarFS на произвольном блочном устройстве или кластере хранения.

Ответ: Patroni с DCS (etcd/Consul) – единый источник истины о том, кто сейчас мастер. Эпоха увеличивается при каждом failover. Shared storage с fencing – при переключении новый мастер получает эксклюзивное право на запись в общее хранилище. Даже если на реплике случайно или намеренно выполнить promote, эта операция провалится – реплика не сможет перемонтировать storage в режим RW, так как shared storage уже захвачен действующим мастером. HAProxy в этой схеме отвечает только за маршрутизацию клиентского трафика, но не за предотвращение split-brain – эту работу делают Patroni и shared storage. Так что потеря связи с HAProxy не позволяет старому мастеру навредить данным.

ProxySQL с группой репликации – в нашей архитектуре мы используем ProxySQL, в котором группа репликации допускает только один пишущий узел. Роли узлов периодически проверяются в отдельном потоке мониторнга. Это гарантирует, что даже если какой-то узел по ошибке считает себя мастером, пишущий трафик на него не пойдёт. Таким образом, даже при полной потере связи между компонентами, ни один узел не сможет несанкционированно писать в данные.

Ответ: Нет, мы не используем ИИ для анализа логов

Ответ: Если интересуют изменения, то всё-таки - log_statement=mod должно вам подойти - all будет включать в себя и запросы (SELECT), которые вряд ли будут интересовать безопасников. Возможно, отделу безопасности не хочется видеть абсолютно все изменения, а только изменения на каких-то конкретных таблицах? Ведь объём изменений в БД очень велик и со временем он начнёт превышать размер самой БД. Если можно ограничиться конкретными таблицами, то можно посмотреть в сторону дополнительных расширений типа pgaudit или рассмотреть создание триггеров, на интересующих их таблицах. В любом случае, нужно исходить именно от поставленной задачи.