Pull to refresh

Эволюция отказоустойчивости в PostgreSQL

Reading time 5 min
Views 12K
Original author: Gulcin Yildirim
Мы активно готовимся к PG Day'17, расширяем тематику конференции, поэтому в скором времени вас ждет большое количество интереснейших постов не только о PostgreSQL, но и о других широко используемых базах данных. Сегодня хотим предложить вашему вниманию перевод статьи Gulcin Yildirim, которая послужила основой для ее доклада на PG Conf Europe'16.

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



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

PostgreSQL в двух словах


PostgreSQL отказоустойчив по своей природе. Во-первых, это продвинутая система управления базами данных с открытым исходным кодом, и в этом году отпразднуется её 20-летний юбилей [прим. пер.: юбилей состоялся в 2016 году, торжественное поздравление от русского сообщества прошло на заключительном вечере PG Day’16 Russia]. Следовательно, это проверенная технология с активным сообществом, благодаря которому она активно развивается.

PostgreSQL является SQL-совместимым (SQL: 2011) и полностью соответствует требованиям ACID (атомарность, согласованность, изолированность, надежность).

Примечание: A(tomicity) C(onsistency) I(solation) D(urability) в PostgreSQL

Атомарность гарантирует, что результаты транзакции будут видны полностью или совсем не видны внутри других транзакций, но транзакция не должна быть атомарна по отношению к самой себе. PostgreSQL отличается согласованностью, и определяемые системой ограничения, продиктованные принципом согласованности, применяются к результатам транзакций. То есть после завершения транзакции данные должны оставаться в непротиворечивом состоянии. Выполняемые одновременно транзакции не влияют друг на друга, что говорит об изолированности (мы поговорим об уровнях изолированности транзакций чуть позже в этом посте). Когда транзакция завершена, её результаты не будут потеряны, вне зависимости от последующих сбоев, и это делает PostgreSQL надежным.

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

PostgreSQL позволяет выполнять синхронные и асинхронные транзакции, PITR (Point-in-time Recovery — восстановление на момент времени) и MVCC (Multiversion concurrency control — Управление конкурентным доступом с помощью многоверсионности). Все эти концепции в определённой степени относятся к отказоустойчивости, и я постараюсь описать их воздействие в процессе объяснения основных понятий и их приложений в PostgreSQL.

PostgreSQL надежен!


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

Опционально можно создавать базы данных с блоками данных с контрольными суммами (data block checksums) для диагностики аппаратных неисправностей. Существует множество механизмов резервного копирования с полным и детализированным PITR на случай, если потребуется детальное восстановление. Также доступны различные инструменты для диагностики.

Репликация баз данных поддерживается изначально. Синхронная репликация, при правильной настройке и управлении, обеспечивает более высокую, по сравнению с “5 девятками” (99.999%), степень доступности и защиту данных.

Принимая во внимание все вышеперечисленные факты, можно с лёгкостью утверждать, что PostgreSQL надежен!

Отказоустойчивость PostgreSQL: WAL


WAL — write ahead logging — является основной системой отказоустойчивости для PostgreSQL.

WAL состоит из серии бинарных файлов, записанных в субдиректории pg_xlog директории данных PostgreSQL. Каждое изменение, внесенное в базу данных, сначала записывается в WAL, отсюда и название «упреждающий» журнал, созвучное «журналу транзакций». Когда транзакция завершается, поведением по умолчанию — и наиболее безопасным — будет форсировать записи WAL на диск.

В случае сбоя PostgreSQL WAL будет воспроизведен, что вернет базу данных в момент завершения последней транзакции и, таким образом, обеспечит сохранность любых изменений базы данных.

Транзакция? Commit?


Изменения в базе данных сами по себе не записываются на диск в момент завершения транзакции. Они записываются спустя какое-то время фоновыми процессами writer & checkpointer на хорошо настроенном сервере. (Посмотрите описание WAL выше)

Транзакции — это фундаментальное понятие всех систем баз данных. Отличительной чертой транзакции является то, что она связывает несколько шагов в единую «всё-или-ничего» операцию.

Примечание: Транзакции в PostgreSQL

PostgreSQL фактически рассматривает каждый SQL запрос как выполняемый внутри транзакции. Если вы не пишете команду BEGIN, то каждый отдельный запрос будет иметь неявные команды BEGIN и (в случае успеха) COMMIT в начале и в конце соответственно. Группа запросов, обернутая в BEGIN и COMMIT, иногда называется блоком транзакции.

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

Примечание: Изолированность транзакций

Стандарт SQL определяет 4 уровня изолированности транзакций: Чтение незавершенного, Чтение завершенного, Повторное чтение, Сериализация.

Таблица 1: Уровни изолированности стандартной SQL транзакции
Уровень изолированности «Грязное» чтение Неповторяемое чтение Фантомное чтение Аномалия сериализации
Чтение незавершенного Разрешено, но не в PG Возможно Возможно Возможно
Чтение завершенного Невозможно Возможно Возможно Возможно
Повторное чтение Невозможно Невозможно Разрешено, но не в PG Возможно
Сериализация Невозможно Невозможно Невозможно Невозможно

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

Для более подробной информации по этой теме изучите документацию Постгреса об изолированности транзакций.

Контрольная точка


Аварийное восстановление воспроизводит WAL, но с какого момента начинается восстановление?

Восстановление начинается с точек в WAL, известных как контрольные точки (checkpoints). Длительность аварийного восстановления зависит от количества изменений в журнале транзакций с момента последней контрольной точки. Контрольная точка — это известная безопасная точка начала восстановления, поскольку она гарантирует, что предыдущие изменения базы данных уже были записаны на диск.

Контрольная точка может быть немедленной или запланированной. Немедленные контрольные точки появляются вследствие каких-либо действий привилегированного пользователя (суперюзера), например, командой CHECKPOINT или другими. Запланированные контрольные точки выставляются Постгресом автоматически.

Заключение


В этом посте мы перечислили важные функции PostgreSQL, связанные с его отказоустойчивостью. Были упомянуты упреждающее журналирование, транзакция, уровни изолированности, контрольные точки и аварийное восстановление. В следующем посте мы продолжим тему рассказом о репликации в PostgreSQL.
Tags:
Hubs:
+8
Comments 23
Comments Comments 23

Articles