PGConf.Russia 2023

Колоссальное значение сейчас приобретает шардинг. Размеры современных БД перешагивают 100 терабайтные пределы, вертикальное масштабирование, добавление реплик, содержащих полную физическую копию БД, становится затруднительным, особенно при дефиците вычислительных ресурсов. Шардирование базы данных – это способ горизонтально масштабироваться, разделив данные между независимыми друг от друга вычислительными узлами.

В мире PostgreSQL существуют как давно известные инструменты масштабирования: CitusDB, Greenplum, так и решения нового поколения – Cockroach DB, Yugabyte DB, SPQR, Shardman.

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

Расскажу о частых ошибках при настройке отказоустойчивого кластера Corosync-Pacemaker. Зачастую эти ошибки приводят к фатальным последствиям, и как следствие - к отказу от выбранного решения в пользу других. Хотите рецепт "правильного" кластера?

Во встроенной логической репликации PostgreSQL с версии 9.5 есть механизм replication origin, позволяющий отслеживать процесс логической репликации с конкретного узла. В 16 версию будет включен патч, позволяющий настраивать циклическую репликацию без повторения изменений, пользуясь этим механизмом. В первых обзорах за внешнее сходство получающегося кластера с мультимастером Postgres Pro фичу окрестили "встроенным мультимастером" - разберемся, насколько они похожи на самом деле, и посмотрим, что там внутри. Ожидается, что слушатели имеют некоторое представление о внутреннем устройстве WAL и его месте в работе PostgreSQL. 

Рассматривается кейс дельта миграции данных, особенности захвата изменений с использованием Debezium и их последующего применения в целевую БД. Приводятся различные варианты конфигураций, сравнительные тесты.