Источник

Друзья, всех с прошедшим вчера Днем программиста! Жизни без багов и красивейшего кода!)

Мы продолжаем разбор облачных сервисов Техносерв Cloud и сегодня детально разложим, из чего состоит наша облачная база данных. Если заглянуть в результаты исследования, проведенного IDG Connect по заказу Oracle, увидим, что DBaaS скоро будет самым востребованным сервисом частного облака. Растет и число публичных сервисов DBaaS.

Снижение затрат за счет консолидации ресурсов, масштабирование по мере необходимости, контроль расходов, доступ к данным из любого места – всё это факторы, влияющие на выбор в пользу облачной базы данных. На рынке облачных услуг свои базы данных предлагают его ведущие игроки – Amazon Web Services, IBM, Microsoft и Oracle. Но есть одна проблема — все они разворачивают БД за пределами России, более того, далеко не все из них предлагают сервис – администрирование, управление производительностью, круглосуточную техническую поддержку (желательно на русском языке), – а только платформу.

Чтобы ответить на этот запрос рынка, мы запустили свой сервис и стали единственным российским облачный провайдером, работающим с четырьмя основными базами данных под ФЗ-152 и ФЗ-242.

Привет, Хабр!

В этой статье мы создадим готовый шаблон-монолит, который можно брать за основу нового fullstack приложения как скелет для навешивания функционала.

Эта статья будет полезна, если вы:

• Начинающий  fullstack-разработчик;
• Стартапер, который пишет MVP чтобы проверить гипотезу.

Сегодня я хочу поговорить с вами про такую замечательную вещь как Point in time recovery (PITR) в PostgreSQL.

Механизм восстановления на определенную точку во времени работает таким образом – у нас есть базовый бэкап, созданный при помощи какой-либо утилиты создания бэкапов (например pg_basebackup), а также набор журнальных файлов, постепенно применяя (накатывая) который, мы можем восстановиться до указанной точки.

Звучит это довольно просто, но, как водится, в каждой простой вещи есть какие-то нюансы, вот о них мы сегодня с вами и поговорим.

В статье описывается один из способов обновления дистибутива операционной системы с работающим кластером баз данных Postgres Pro Standard версии 11. В дальнейшем, для краткости кластер баз данных Postgres Pro Standard 11 будем называть Postgrespro, Centos7 - Centos, а AlmaLinux8 - Almalinux. Способ заключается в том чтобы настроить физическую репликацию Postgrespro между разными дистрибутивами операционной системы с последующим переводом слейва в режим мастера. При чтении множества статей о настройке физической репликации я нигде не встречал упоминание о том, что так делать нельзя. Естественно, что архитектура Centos и Almalinux должны совпадать, а так же должны совпадать мажорные версии Postgrespro.