Еволюція відмовостійкості в PostgreSQL

Ми активно готуємося до 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.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.