Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.

В Kubernetes короткий жизненный цикл подов — норма. Но когда лидер-узел MySQL внезапно исчезает, рискуешь потерять не только доступность, но и согласованность данных. Оператор Moco предлагает решение: полусинхронная репликация, автоматический failover и восстановление с PITR — всё это без боли миграции на полностью синхронную репликацию.

В статье — детали репликации, бэкапов, PITR, switchover и нюансов работы с пользовательскими образами. А также честно — чем он лучше (и хуже) альтернатив, и стоит ли его рассматривать для продакшена.

Однажды поздним воскресным вечером ничто не предвещало неприятностей, пока не поступило сообщение о проблемах с репликацией в продуктовом кластере ClickHouse. В статье поделились опытом восстановления сервиса после сбоя и разобрали  репликацию материализованных представлений.

В обзоре узнаете, как графический интерфейс PG Back Web значительно облегчает управление резервными копиями PostgreSQL. Мы покажем, как настраивать резервные копии всего за несколько кликов.

Осенью 2023 года вышла Alpha-версия Percona Everest — нового продукта от компании Percona. Это cloud-native database platform — инструмент с графическим интерфейсом для управления кластерами баз данных, развёрнутыми в Kubernetes.

22 февраля 2024 года Percona Everest перешла в состояние Beta. Обновлённый продукт сильно отличается от первой версии — разработчики проделали большой объем работы. В сегодняшней статье разберём, как выглядит Beta-версия Percona Everest и как её установить. Также рассмотрим, чего не хватает инструменту, на наш взгляд, на текущий момент.

В одном из проектов мне пришлось столкнуться с классической ситуацией: нагрузка со стороны приложения на реляционную БД была чрезвычайно высока из-за большого RPS (requests per second). Однако реальный процент уникальных данных, извлекаемых приложением из БД, был относительно невелик. К тому же, медленный ответ БД порождал рост числа подключений к ней со стороны приложения — это еще больше увеличивало нагрузку и вызвало эффект снежного кома.

Выбранное решение для этой проблемы закономерно: кэширование данных. В роли кэша выступило хранилище memcached, которое приняло на себя основную нагрузку от запросов на получение данных. Однако при переезде приложения в Kubernetes возникли сложности…

В нашей внутренней production-инфраструктуре есть не слишком критичный участок, на котором периодически обкатываются различные технические решения, в том числе и различные версии Rook для stateful-приложений. На момент проведения описываемых работ эта часть инфраструктуры работала на основе Kubernetes-кластера версии 1.15, и возникла потребность в его обновлении.

За заказ persistent volumes в кластере отвечал Rook версии 0.9. Мало того, что этот оператор сам по себе был старой версии, его Helm-релиз содержал ресурсы с deprecated-версиями API, что препятствовало обновлению кластера. Решив не возиться с обновлением Rook «вживую», мы стали полностью разбирать его.

Внимание! Это история провала, не повторяйте описанные ниже действия в production, не прочитав внимательно до конца.

Итак, вынос данных в хранилища StorageClass’ов, не управляемых Rook’ом, шел уже несколько часов успешно…