PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

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

„Парадоксално, но вярно е да се каже, че колкото повече знаем, толкова по-невежи ставаме в абсолютния смисъл, защото само чрез просветлението осъзнаваме своите ограничения. Точно един от най-удовлетворяващите резултати от интелектуалната еволюция е непрекъснатото отваряне на нови и по-големи перспективи." Никола Тесла

PostgreSQL е страхотен проект и се развива с невероятна скорост. Ще се съсредоточим върху развитието на възможностите за отказоустойчивост в PostgreSQL във всичките му версии с поредица от публикации в блога.

 PostgreSQL накратко

PostgreSQL е устойчив на грешки по своето естество. Първо, това е усъвършенствана система за управление на база данни с отворен код и ще отпразнува 20-ия си рожден ден тази година. Следователно това е доказана технология и има активна общност, благодарение на която се развива бързо.

PostgreSQL е SQL-съвместим (SQL:2011) и напълно ACID-съвместим (атомност, консистенция, изолация, издръжливост).

PostgreSQL позволява физическа и логическа репликация и има вградени решения за физическа и логическа репликация. Ще говорим за методите за репликация (в следващите публикации в блога) в PostgreSQL по отношение на толерантността на грешки.

PostgreSQL позволява синхронни и асинхронни транзакции, PITR (Възстановяване по време) и MVCC (Многоверсионен контрол на паралелност). Всички тези концепции са свързани с отказоустойчивостта на някакво ниво и аз ще се опитам да обясня ефектите им, докато обяснявам необходимите термини и техните приложения в PostgreSQL.

PostgreSQL е стабилен!

Всички действия в базата данни се извършват в рамките на транзакции , защитено срегистрационен файл на транзакции който ще извърши автоматично възстановяване при срив в случай на повреда на софтуера.

Базите данни могат да бъдат създадени по избор с контролни суми за блокове от данни за да помогне за диагностицирането на хардуерни грешки. Съществуват множество механизми за архивиране, с пълен и подробен  PITR, в случай на необходимост от подробно възстановяване. Предлагат се различни диагностични инструменти.

Репликацията на база данни се поддържа първоначално. Синхронна репликация може да осигури повече от „5 деветки“ (99,999 процента) наличност и защита на данните, ако са правилно конфигурирани и управлявани.

Имайки предвид фактите по-горе, можем лесно да твърдим, че PostgreSQL е стабилен!

Толерантност към грешки на PostgreSQL:WAL

Записването напред е основната система за толерантност на грешки за PostgreSQL.

WAL се състои от поредица от двоични файлове, записани в поддиректорията pg_xlog на директорията с данни на PostgreSQL. Всяка промяна, направена в базата данни, се записва първо в WAL, откъдето идва и името на дневника „запис напред“, като синоним на „дневник на транзакциите“. Когато транзакция се извърши, поведението по подразбиране — и безопасно — е да се принудят WAL записите на диск.

Ако PostgreSQL се срине, WAL ще бъде възпроизведен отново, което връща базата данни до точката на последната ангажирана транзакция и по този начин гарантира трайността на всякакви промени в базата данни.

Транзакция? Обвързване?

Самите промени в базата данни не се записват на диск при извършване на транзакция. Тези промени се записват на диска малко по-късно от фоновия записващ или контролен указател на добре настроен сървър. (Проверете описанието на WAL по-горе. )

Транзакциите са основна концепция на всички системи за бази данни. Основният момент на транзакцията е, че тя обединява няколко стъпки в една единствена операция „всичко или нищо“.

Междинните състояния между стъпките не са видими за други едновременни транзакции и ако възникне някаква грешка, която пречи на транзакцията да бъде завършена, тогава нито една от стъпките не засяга базата данни изобщо. PostgreSQL не поддържа мръсно четене (транзакцията чете данни, записани от едновременна незавършена транзакция ).

Контролен пункт

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

Възстановяването започва от точки в WAL, известни като контролни точки . Продължителността на възстановяването при срив зависи от броя на промените в регистъра на транзакциите от последната контролна точка. Контролната точка е известна безопасна отправна точка за възстановяване, тъй като гарантира, че всички предишни промени в базата данни вече са записани на диск.

Контролната точка може да бъде или незабавна илинасрочено . Незабавните контролни точки се задействат от някакво действие на суперпотребител, като например CHECKPOINT команда или друго; планираните контролни точки се определят автоматично от PostgreSQL.

Заключение

В тази публикация в блога изброихме важни характеристики на PostgreSQL, които са свързани с толерантността на грешки в PostgreSQL. Споменахме записване напред за запис, транзакция, комит, нива на изолация, контролни точки и възстановяване при срив. Ще продължим с репликацията на PostgreSQL в следващата публикация в блога.

Препратки:

PostgreSQL документация

Готварска книга за администриране на PostgreSQL 9 – второ издание


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Мигриране на PostgreSQL към облака – Сравняване на решения от Amazon, Google и Microsoft

  2. Как да вмъкнете CSV данни в PostgreSQL база данни (отдалечена база данни)

  3. PostgreSQL 8.4 предоставя DML привилегии за всички таблици на роля

  4. TypeError:Обектът 'int' не поддържа индексиране

  5. Инсталирането на pip е неуспешно с /usr/bin/clang:Няма такъв файл или директория