Не секрет, что стейт-машины среди нас. Они буквально повсюду, от UI до сетевого стека. Иногда сложные, иногда простые. Иногда security-related, иногда не очень. Но, зачастую, довольно увлекательны для изучения :) Сегодня я хочу рассказать об одном забавном случае с PostgreSQL — CVE-2018-10915, которая позволяла повышать привилегии до superuser.

Есть мнение, что будущее за DB as Service. Стоит ли всем подряд увольнять DBA и переходить в публичное облако или стремиться создать приватное облако на Docker с Kubernetes? Трое экспертов из Data Egret — Алексей Лесовский, Виктор Егоров и Андрей Сальников — на канале #RuPostgres в прямом эфире поделились мнением, для каких именно проектов подойдут облачные модели.

Модератором и ведущим беседы выступил Николай Самохвалов, основатель Postgres.ai и сооснователь сообщества RuPostgres.org.



Под катом — расшифровка беседы.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Новости

Microsoft приобрела Citus Data

Безусловно, главная новость в мире PostgreSQL. Об этом есть сообщение на сайте Citus, равно как и на сайте MS.

Postgres Pro Enterprise Certified

СУБД Postgres Pro Enterprise получила сертификат ФСТЭК, и теперь в наборе Postgres Pro есть и «Сертифицированная версия Postgres Pro Enterprise». До этого сертификат, необходимый для работы с персональными данными, имела только Postgres Pro Standard («Сертифицированная версия Postgres Pro»). Подробности на сайте.

credativ: PostgreSQL Competence Center

Германская фирма credativ, до того известная в Европе и Азии, приобрела фирму OmniTI, чтобы выйти на американский рынок. credativ специализируется на развертывании и поддержке проектов open source. Теперь в США откроется PostgreSQL Competence Center, который будет заниматься высококритичными проектами и поддерживать БД в течение всего их жизненного цикла.

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



Дело в том, что файлы баз данных Greenplum версий 4 и 5 не совместимы между собой, и поэтому простой апгрейд от одной версии к другой невозможен. Миграцию данных можно провести только через выгрузку и загрузку данных. В этом посте я расскажу о возможных вариантах этой миграции.

Продолжение публикации «Сервер push сообщений»

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



На картинке видна прерывистая линия разделитель, при наведении она становится желто-черно- полосатой. Передвигая разделитель, можно отрегулировать высоту поля для ввода сообщений.

Аналогично можно изменить ширину списка контактов и списка сообщений.

Отправка сообщений анимирована, какой либо анимации при отправке сообщений в других программах не было.

Для фона списка контактов используется градиент серого и розового, похожее сочетание можно встретить на небе в виде зарева.

Предлагаем вашему вниманию перевод статьи Джозефа Хеллерштейна «Looking Back at Postgres», опубликованной в соответствии с международной лицензией Creative Commons «С указанием авторства» версии 4.0 (CC-BY 4.0). Авторы оставляют за собой право распространять эту работу на личных и корпоративных веб-сайтах с надлежащей ссылкой на источник.

Перевод выполнен Еленой Индрупской. От себя добавлю, что «программист, который отчаянно хотел построить систему с многоверсионностью» — судя по всему, Вадим Михеев, ну а «добровольцев из России», переписавших GiST, мы все хорошо знаем.

Аннотация

Это воспоминание о проекте Postgres, выполняемом в Калифорнийском университете в Беркли и возглавляемом Майком Стоунбрейкером (Mike Stonebraker) с середины 1980-х до середины 1990-х годов. В качестве одного из многих личных и исторических воспоминаний, эта статья была запрошена для книги [Bro19], посвященной награждению Стоунбрейкера премией Тьюринга. Поэтому в центре внимания статьи — руководящая роль Стоунбрейкера и его мысли о дизайне. Но Стоунбрейкер никогда не был программистом и не мешал своей команде разработчиков. Кодовая база Postgres была работой команды блестящих студентов и эпизодически—штатных университетских программистов, которые имели немного больше опыта (и только немного большую зарплату), чем студенты. Мне посчастливилось присоединиться к этой команде в качестве студента в последние годы проекта. Я получил полезный материал для этой статьи от некоторых более старших студентов, занятых в проекте, но любые ошибки или упущения являются моими. Если вы заметили какие-либо из них, пожалуйста, свяжитесь со мной, и я постараюсь их исправить.

В любом современном интернет сервисе можно выделить всего две основные функции:

• Первая — это авторизация пользователей.
• Вторая — это моментальная отправка некоего события с сервера на клиент.

Первый пункт, думаю, в пояснении не нуждается.

Второй пункт, это клиент серверная технология, но наоборот. Клиент не делает периодически запрос на сервер — есть ли новые сообщения. Сервер, при появлении некоего события, отравляет сообщение сразу клиенту.

Для лучшего понимания сервис не некий сферичный в вакууме. Сервис можно представить как:

• Папка с файлами в облаке. Информация о изменении, добавлении и удалении пересылается другим пользователям или текущему пользователю, но на другие устройства.
• Компьютерная программа чтения логов сервера, при появлении записей «error» отсылающая содержимое записи пользователю на мобильный телефон.
• Видео-глазок (камера), делающий снимки при движении около двери квартиры.
• Сервис получающий телеметрию из приложения android-auto.
• Похожий на предыдущий пункт сервис, позволяющий узнать дошел ли ребенок до школы или пришел из школы домой.

Список можно расширять до бесконечности, приведены, как пример, лишь наиболее известные варианты использования.

Практически все приведенные примеры сервисов можно представить в виде «мессенджера». Часть из примеров именно так и описывалась, видел статьи, как подключить камеру и отправлять снимки в один известный мессенджер.

Не так давно была статья что за сервисом камер в дверных глазках, вместо искуственного интелекта наблюдали посторонние люди. Не буду заострять внимание на бесплатных сервисах от больших «добрых» корпораций. Как говориться в известной пословице «Бесплатный сыр бывает в мышеловке» и руководствуясь другой пословицей «Своя рубашка ближе к телу», свой «сервис» лучше.

Код скриптов сервера открыт и бесплатен

Привет друзья. Ни для кого не секрет, что работая на крупных проектах со сложной логикой, Active Record становится не помощником, а обузой. Представьте, что вам необходимо сделать очень сложный запрос для PostgreSQL нативным образом (на чистом SQL), где должно присутствовать некоторое количество переменных. Но в Rails есть одна неприятная мелочь, функционал выполнения нативных запросов не позволяет использовать именованные биндинги. Но решение есть :) Опробовано и успешно внедрено на проекте с Rails API 5.2 + Ruby 2.6.0 + Postgres 11.

Это первая часть статьи, в которой я расскажу о том, как мы построили процесс работы над большим проектом по миграции БД: про безопасные эксперименты, командное планирование и кросс-командное взаимодействие. В следующих статьях подробней расскажу про технические проблемы, которые мы решали: про масштабирование и отказоустойчивость PostgreSQL и нагрузочное тестирование.



Долгое время основной базой данных в RealtimeBoard был Redis. Мы хранили в нём всю основную информацию: данные о пользователях, аккаунтах, досках и т.д. Всё работало быстро, но мы столкнулись с рядом проблем.

Проблемы с Redis

1. Зависимость от сетевой задержки. Сейчас в нашем облаке она составляет порядка 20 мск, но при её увеличении приложение начнёт работать очень медленно.
2. Отсутствие индексов, которые нужны нам на уровне бизнес-логики. Их самостоятельная реализация может усложнить бизнес-логику и привести к неконсистентности данных.
3. Сложность кода также усложняет обеспечение консистентности данных.
4. Ресурсоёмкость запросов с выборками.

Эти проблемы вместе с ростом количества данных на серверах послужили причиной для миграции БД.

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).