Консенсус, Postgres, Мультимастер
Postgres Pro Multimaster - это расширение Postgres (и набор патчей для ядра), обеспечивающее высокую доступность (HA) со строгой согласованностью и масштабируемостью чтения. Он образует симметричный кластер без общего доступа, синхронно реплицирующий данные и автоматически выполняющий аварийное восстановление. В течение последнего года мы приложили значительные усилия, чтобы убедиться и доказать, что согласованность сохраняется во всех сценариях. Новая версия, которая будет выпущена как часть Postgres Pro Enterprise 13, использует алгоритм Paxos для определения результата транзакции и оригинальный протокол, управляющий процессом восстановления; мы использовали TLA+ и TLC model checker для проверки его правильности. Я расскажу, как все это работает и почему в некоторых случаях multimaster может быть привлекательной альтернативой традиционным HA решениям на основе потоковой репликации.
Multimaster теперь имеет открытый исходный код и доступен по адресу: https://github.com/postgrespro/mmts
Чтобы сделать доклад менее узкоспециализированным и более привлекательным для широкой аудитории, в первой части я расскажу о том, как в целом современные СУБД (в основном так называемые NewSQL СУБД) обеспечивают отказоустойчивость. В частности, я остановлюсь на следующих моментах:
что такое строго согласованная СУБД и какие накладные расходы с этим связаны; что такое распределённый консенсус, Paxos, Raft; как они здесь помогают?
Я не буду пытаться объяснять какие-либо алгоритмы построчно; это едва ли осмысленно с учетом ограничений по времени, и на эту тему есть много полезной литературы. Цель здесь скорее в том чтобы познакомить с областью и задать в ней ориентиры.
Видео
Другие доклады
-
Daniel Westermann dbi services Principal Consultant
Как переносить данные из Oracle в PostgreSQL и обратно
Использование PostgreSQL стало обычным делом во множестве организаций. В большинстве случаев PostgreSQL устанавливают в дополнение к уже имеющимся СУБД Oracle, и довольно скоро возникает закономерный вопрос: как перебрасывать данные из Oracle в PostgreSQL и наоборот? Давайте перенесёмся в прошлое, в март 2001, когда вышло новое расширение SQL стандарта, определившее общие принципы создания API для управления внешними данными: SQL/MED (ISO/IEC 9075-9:2008). Сообщество PostgreSQL довольно быстро создало фреймворк для использования рекомендаций стандарта в виде так называемых обёрток сторонних данных (foreign data wrappers). Это случилось в 2011 с выходом PostgreSQL 9.1. С тех пор число обёрток сторонних данных постоянно растёт. Сегодня благодаря им PostgreSQL может интегрировать данные почти из любого внешнего источника, будь то обычные файлы, другие реляционные СУБД или даже неструктурированные данные. В рамках этого доклада мы рассмотрим обёртку сторонних данных для Oracle и то, как её можно использовать для получения данных из Oracle в PostgreSQL. Однако обратное тоже верно: данные из PostgreSQL также можно отправить в Oracle, и это может быть важно для соблюдения требований. Обещаю, что в докладе будет две части: слайды и много демонстраций.
-
Федор Сигаев Postgres Professional технический директорАнтон Дорошкевич ИнфоСофт Руководитель Отдела-ИТ
1С:Предприятие + Постгрес = ...
В диалоге технического директора Postgres Professional, ведущего разработчика PostgreSQL Федор Сигаев и известного 1С-эксперта Антон Дорошкевич обсудят имеющиеся проблемы эксплуатации 1С на Постгресе и их возможные решения.
-
Дмитрий Урсегов Postgres Professional Руководитель группы разработки
Шардман - естественный подход к шардингу в PostgreSQL
Объем данных, с которым работают современные корпоративные и интернет системы, постоянно растет. При этом все сложнее становится иметь и синхронизировать несколько копий данных в разных системах. Возникает необходимость работать с большими объемами данных непосредственно в транзакционной СУБД, Часто такое требование накладывает и логика приложений, которым необходимы результаты в реальном времени. В докладе рассмотрим какой может быть универсальная распределенная транзакционная СУБД. Разберем такие аспекты как типы нагрузки и их приоритизация, динамическое выделение ресурсов, уровень консистентности. Расскажем на каких инструментах в PostgreSQL можно построить такую систему, что у нас уже получилось и какие задачи еще предстоит решить.
-
Tatsuro Yamada NTT Comware Ведущий специалист по базам данныхJulien Rouhaud Разработчик
Построение автоматического консультанта и инструментов настройки производительности в PostgreSQL
PostgreSQL - зрелая реляционная СУБД, её история насчитывает более 30 лет. За последний год её оптимизатор запросов стал лучше, и обычно он создаёт хорошие планы выполнения запросов.
Но всегда ли эти планы выполнения запросов хороши? Чтобы оптимизировать процесс их создания, приходится пользоваться предположениями, чтобы планы выполнения запросов создавались достаточно быстро. Некоторые из этих предположений проверить довольно легко (например, актуальность статистики), другие сложнее (например, надо убедиться, что правильные индексы были созданы), а некоторые проверить почти невозможно (например, убедиться, что выборки достаточно репрезентативны даже для ассиметричного повторного секционирования данных). Сегодня из-за всех этих предположений администратор базы данных не всегда осознаёт, что он мог бы добиться значительного улучшения производительности.
Чтобы помочь администраторам баз данных работать с действительно хорошим планом выполнения запросов, ниже мы представим несколько инструментов, которые могли бы помочь решить вышеупомянутые проблемы. Мы расскажем о консультанте для недостающих индексов, поиске недостающей статистики для создания новых метрик, а также информации для исправления ошибок в оценке строк (при этом порядок выполняемых операций соединения и оператор соединения определяются автоматически).
- pg_qualstats предоставляет подсказки для создания новых индексов и расширенной статистики чтобы собрать много предикатных статистических данных о производственной нагрузке.
- pg_plan_advsr создаёт альтернативные планы выполнения запросов автоматически для анализа информации об итеративном выполнении запросов, чтобы исправить ошибку оценки строк.
В рамках этого доклада мы объясним, как устроены эти инструменты, что можно делать с их помощью, и как эффективно использовать оба инструмента вместе. Мы также упомянем другие инструменты для решения смежных проблем. Поэтому наш доклад будет полезен администраторам баз данных, которые заинтересованы в улучшении производительности при выполнении запросов или хотят проверить адекватность существующих настроек, индексов или статистики.