в AWS без каких-либо изменений.
Во время работы этой базы данных возникает рассинхронизация в работе через pgpool - данные то есть в базе, то их нет при обращении из приложения.
Очевидно, что работает некорректно синхронизация между репликами, когда данные из одной бд не записаны на standby-реплику.
При этом в replication_delay (show pool_nodes;) стоит 0.
После экспериментов с различными images для pgpool и реплик, начала накапливаться очередь в replication_delay и растет далее.
Почему возникает рассинхронизация в данных между репликами, как исследовать проблему и решить ее?
мб проще всего взять другой оператор, в чате говорят что зеланд надёжный и проверенный
Выкинь нахер bitnami
А какие проблемы с bitnami у Вас были? Принимаем решение с чем остаться как для stage, так и в production.
крайне отрицательный опыт 1) кучу шела в entrypoint. Невозможно дебажить ошибки в случае проблем. В логах от entrypoiunt полная херня не связанная с настоящей ошибкой 2) не работает с нормальными политками (например запрет запуска от root и readOnlyFileSystem: true) 3) Тот же чарт postgres от них вообще с readOnlyFileSystem: true не завести, поскольку свои volumes с emptyDir для /tmp например не притащить. То есть нет достаточной гибкости в чартах 4) Плохая документация по технологиям HA которые они используются в чартах. В том же mysql чарте используется mysql-router и вроде бы групповая репликация - в доках чарта об этом вообще ни слова. 5) неадекватные решения по скриптам в entrypoint. Например в mysql чарте, они зачем-то хотят писать в /opt/bitnami/mysql/conf. В которой итак уже есть какие-то конфиги. Вместо того чтобы выделить отдельную папку только для генерируемых конфигов. https://t.me/kubernetes_ru/437682
Обсуждают сегодня