Профиль Статьи 229Подписчики 111KСотрудники 24

Восстановление данных PostgreSQL после потери pg_control

4 мин

32K

Блог компании Postgres ProfessionalPostgreSQL*

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

Данные в журнал пишутся до того как пользователь базы данных получит сообщение об успешном применении изменений. Этот журнал называется журналом упреждающей записи (Write-Ahead Log или просто WAL), а файлы журнала хранятся в каталоге pg_xlog. Также периодически PostgreSQL сбрасывает измененные аккумулированные данные из оперативной памяти на диск. Этот процесс согласования данных называется контрольной точкой (checkpoint). Контрольная точка выполняется также при каждом штатном выключении PostgreSQL.

Информация о том, с какими внутренними значениями завершилась контрольная точка, хранится в файле global/pg_control и потому этот файл должен быть доступен СУБД еще до момента восстановления данных. Если PostgreSQL отключается нештатно, то изменения из файлов журнала (pg_xlog) применяются к файлам БД, начиная с позиции последней контрольной точки. Этот процесс называется восстановлением данных.

В файле pg_control находится информация:

версия формата control-файла,
контрольная сумма записанных в этот файл данных,
версия формата файлов БД,
уникальный идентификатор экземпляра БД,
текущее состояние: работает/остановлен,
позиция в журнале, соответствующая запущенной и предыдущей контрольным точкам,
текущая ветвь времени (timeline),
максимальный видимый номер транзакции (xid),
максимальный номер внутреннего счетчика объектов (oid),
время создания,
и многое другое.

Посмотреть содержимое pg_control можно при помощи утилиты pg_controldata:

$ pg_controldata /var/lib/pgsql/9.5/data

pg_control version number:            942
Catalog version number:               201510051
Database system identifier:           6242923005164171508
Database cluster state:               in production
pg_control last modified:             Fri Apr 29 01:00:00 2016
Latest checkpoint location:           EEAF/BAA5520
Prior checkpoint location:            EEAF/BAA5440
...
Latest checkpoint's NextXID:          7/876524573
Latest checkpoint's NextOID:          264355612
Latest checkpoint's NextMultiXactId:  134512401
Latest checkpoint's NextMultiOffset:  547842659
...

Читать дальше →

+25

plumqqz 29 фев 2016 в 11:12

Таблица как параметр в Postgresql

4 мин

23K

Блог компании Postgres ProfessionalPostgreSQL*SQL*

Часто видно жалобы на то, что параметры "не работают". Как же они не работают?

А вот так:

select * from $1 where ...;

Читать дальше →

+12

plumqqz 16 фев 2016 в 15:50

Использование функций в PostgreSQL как параметризированных представлений

6 мин

44K

Блог компании Postgres ProfessionalPostgreSQL*SQL*

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

Читать дальше →

+21

erogov 27 янв 2016 в 11:46

Обработка запросов в Oracle и PostgreSQL: следствия одного решения

21 мин

33K

Блог компании Postgres ProfessionalOracle*PostgreSQL*

Обработка запросов SQL и в Оракле, и в Постгресе имеет много общего. Так или иначе, надо выполнить синтаксический разбор, проверить семантику (для чего потребуется метаинформация, и не важно, называется ли это «словарь данных» или «системный каталог»), выполнить какие-то преобразования, построить оптимальный план выполнения (в обеих системах основанный на стоимости, а следовательно требующий заранее собранной статистики).

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

В статье мы попытаемся проследить, как из-за разницы в одном архитектурном решении логически следует совершенно разная идеология работы в запросами в двух СУБД.

Приведенные примеры (которые выполнялись на версиях Oracle 11.2 XE и PostgreSQL 9.4) содержат время выполнения запросов. Нас интересуют только относительные величины: во сколько раз изменилось время выполнения после внесения в запрос тех или иных изменений. При этом абсолютные цифры могут отличаться на порядки в зависимости от аппаратуры, нагрузки и настроек. Чтобы не давать повод для бессмысленных выводов на их основании, все абсолютные значения в статье отмасштабированы так, чтобы один из запросов составлял в обеих системах 10 секунд.

Читать дальше →

+24

lubennikovaav 22 дек 2015 в 12:36

Курс «Hacking PostgreSQL» — уже скоро

4 мин

20K

Блог компании Postgres ProfessionalPostgreSQL*

Привет всем!

Сегодня я рада анонсировать курс “Hacking PostgreSQL” из 16 занятий, на которых мы вместе будем исследовать особенности архитектуры открытой СУБД и вносить изменения на уровне исходного кода. Курс будет проходить в Москве, на площадке компании Postgres Professional. Начало курса запланировано на февраль 2016 года. Лекции начнутся сразу после февральской конференции pgconf.ru и будут проходить один раз в неделю вечером. Видеозаписи и материалы лекций мы будем выкладывать по мере обработки.

Курс собран из личного опыта разработчиков нашей компании, материалов с конференций, статей и вдумчивого чтения документации и исходников. В первую очередь он адресован начинающим разработчикам ядра PostgreSQL. Но он будет интересен и DBA, которым иногда приходится влезать в код, и просто всем неравнодушным к архитектуре большой системы, желающим узнать “А как это работает на самом деле?”

Подробнее о целях и содержании курса

+23

tigvarts 18 дек 2015 в 12:19

Применение машинного обучения для увеличения производительности PostgreSQL

10 мин

22K

Блог компании Postgres ProfessionalPostgreSQL*Data Mining*Машинное обучение*

Машинное обучение занимается поиском скрытых закономерностей в данных. Растущий рост интереса к этой теме в ИТ-сообществе связан с исключительными результатами, получаемыми благодаря ему. Распознавание речи и отсканированных документов, поисковые машины — всё это создано с использованием машинного обучения. В этой статье я расскажу о текущем проекте нашей компании: как применить методы машинного обучения для увеличения производительности СУБД.
В первой части этой статьи разбирается существующий механизм планировщика PostgreSQL, во второй части рассказывается о возможностях его улучшения с применением машинного обучения.

Читать дальше →

+43

stalkerg 4 дек 2015 в 12:08

Доступ к таблицам из Си расширений для Postgres

8 мин

9.6K

Блог компании Postgres ProfessionalPostgreSQL*Программирование*C*

Туториал

Всем привет!

В этот раз я расскажу не про использование Python или очередной трюк с CSS/HTML и, увы, не про то, как я 5 лет портировал Вангеры, а про один важный аспект написания расширений для замечательной СУБД PostgresSQL.

На самом деле, уже есть достаточно много статей о том, как написать расширение для Postgres на Си (к примеру, эта), в том числе и на русском языке. Но, как правило, в них описываются достаточно простые случаи. В этих статьях и инструкциях авторы реализуют функции, которые получают на вход данные, как-то их обрабатывают, а затем возвращают одно число, строку или пользовательский тип. В них нет пояснений, что делать, если из Си кода нужно пробежаться по обычной таблице, существующей в базе, или индексу.

К таблицам из Си можно получить доступ через хорошо описанный но медленный SPI (Server Programming Interface), также есть очень сложный способ, через буферы, а я расскажу про компромиссный вариант. Под катом я постарался дать примеры кода с подробными пояснениями.

Читать дальше →

+21

LarisaPostgres 1 дек 2015 в 11:13

Приглашаем на PGConf 2016 — российскую PostgreSQL конференцию

4 мин

4.7K

Блог компании Postgres ProfessionalPostgreSQL*

3-5 февраля 2016 г. в Москве на площадке Известия-холл (Пушкинская площадь, 5) пройдет международная российская конференция PgConf.Russia 2016. Конференцию организует российское сообщество PostgreSQL при поддержке спонсоров. Генеральный партнер PGConf.RU 2016 — компания Postgres Professional, золотым партнером стала компания Avito.

Эта конференция организуется в Москве уже второй раз. В феврале 2015 г. PGConf.RU собрала 460 участников, став крупнейшим в мире форумом, посвященным PostgreSQL.

Основные темы конференции:

Масштабируемость, производительность, безопасность PostgreSQL.
Разработка ядра PostgreSQL. Внутреннее устройство. Текущие и будущие проекты.
Живой опыт практического использования PostgreSQL в России и за рубежом. Внедрение, миграция, разработка приложений. Доклады «с полей».
Кластер. Отказоустойчивые и масштабируемые системы на базе PostgreSQL
PostgreSQL в России. Российское сообщество. Образование. PostgreSQL в задачах импортозамещения и достижения технологической независимости.

Читать дальше →

+15

smagen 17 ноя 2015 в 02:19

PostgreSQL на многоядерных серверах Power 8

13 мин

26K

Блог компании Postgres ProfessionalPostgreSQL*

Аннотация

При помощи московского представительства компании IBM мы провели тестирование производительности последних версий СУБД PostgreSQL на серверах Power8, изучили масштабируемость зависимость производительности от количества одновременных запросов, нашли узкие места ограничивающие производительность, предложили новые технические решения и добились рекордной производительности.

Введение

В ряде задач практически неограниченного масштабирования по объему обрабатываемых транзакций можно достичь, используя распределённые системы, в которых тем или иным способом поток транзакций распределяется на большое количество серверов. Такое масштабирование часто называют “горизонтальным”. Однако, универсального распределенного решения не существует, кроме того, распределённость имеет свою цену. Архитектура системы должна заранее проектироваться как распределённая. Распределенные системы менее гибки, чем монолитные, к тому же они сложнее в эксплуатации и требуют более высокой квалификации персонала. Одни задачи легче поддаются распараллеливанию, другие — сложнее. Поэтому спрос на высокопроизводительные монолитные системы существует, и достижение возможно лучших результатов по производительности в рамках одного сервера было и остается важной задачей. Это часто называют “вертикальным масштабированием”.

Сущность проблем, возникающих при параллельной обработке большого количества транзакций в монолитных и распределенных системах, одинакова — это конкуренция между транзакциями за доступ к одним и тем же ресурсам. Говоря просто, отдельные процессы работают параллельно и независимо до тех пор, пока не выстраиваются в очередь к какому-либо общему ресурсу (а это может быть как аппаратный ресурс, так и элемент информации, хранящийся в базе данных) и не начинают ожидать друг друга.

Для решения таких проблем существуют механизмы управления доступом к ресурсам — использование блокировок, а также пригодные в некоторых случаях неблокирующие (lock-free) подходы. Рост производительности этих механизмов, а также детализация блокировок дает возможность снизить издержки, связанные с одновременным (конкурентным) доступом.

При этом, если в распределённых системах узким местом оказывается, как правило, сеть, то в монолитных системах, близких к пиковой производительности, её рост ограничивается именно упомянутыми механизмами управления одновременным доступом.

Читать дальше →

+33

1 2 ...

10 11