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

Създаване на студен режим на готовност за PostgreSQL с помощта на Amazon AWS

Необходимостта от постигане на висока наличност на базата данни е доста често срещана задача и често е задължителна. Ако вашата компания има ограничен бюджет, тогава поддържането на роб за репликация (или повече от един), който работи на един и същ доставчик на облак (просто се чака, ако някой ден е необходимо), може да бъде скъпо. В зависимост от типа приложение има някои случаи, в които е необходимо подчинено устройство за репликация, за да се подобри RTO (Цел за време за възстановяване).

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

Студеният режим на готовност е метод за резервиране, при който имате резервен възел (като резервен) за основния. Този възел се използва само по време на главен отказ. През останалото време възелът за студена готовност се изключва и се използва само за зареждане на резервно копие, когато е необходимо.

За да използвате този метод,  е необходимо да имате предварително дефинирана политика за архивиране (с излишък) в съответствие с приемливо RPO (Цел за точка на възстановяване) за компанията. Може да се окаже, че загубата на 12 часа данни е приемлива за бизнеса или загубата на само един час може да бъде голям проблем. Всяка компания и приложение трябва да определят свой собствен стандарт.

В този блог ще научите как да създадете политика за архивиране и как да я възстановите на сървър със студен режим на готовност с помощта на ClusterControl и неговата интеграция с Amazon AWS.

За този блог ще приемем, че вече имате акаунт в AWS и инсталиран ClusterControl. Докато в този пример ще използваме AWS като доставчик на облак, вие можете да използвате друг. Ще използваме следната топология на PostgreSQL, разгърната с помощта на ClusterControl:

  • 1 първичен възел на PostgreSQL
  • 2 PostgreSQL Hot-Standby възела
  • 2 балансира на натоварването (HAProxy + Keepalived)

Създаване на приемлива политика за архивиране

Най-добрата практика за създаване на този тип правила е архивните файлове да се съхраняват на три различни места, едното се съхранява локално на сървъра на базата данни (за по-бързо възстановяване), друго в централизиран сървър за архивиране и последният в облака.

Можете да подобрите това, като също така използвате пълно, инкрементално и диференциално архивиране. С ClusterControl можете да изпълнявате всички горепосочени най-добри практики, всички от една и съща система, с удобен и лесен за използване потребителски интерфейс. Нека започнем със създаването на интеграцията на AWS в ClusterControl.

Конфигуриране на интеграцията на ClusterControl AWS

Отидете на ClusterControl -> Integrations -> Cloud Providers -> Add Cloud Credentials.

Изберете доставчик на облак. Поддържаме AWS, Google Cloud или Azure. В този случай изберете AWS и продължете.

Тук трябва да добавите име, регион по подразбиране и AWS идентификатор на ключ и секретен ключ. За да получите или създадете последните, трябва да отидете в раздела IAM (Управление на идентичността и достъпа) на конзолата за управление на AWS. За повече информация можете да се обърнете към нашата документация или документацията на AWS.

Сега имате създадена интеграция, нека отидем да планираме първото архивиране с помощта на ClusterControl.

Насрочване на архивиране с ClusterControl

Отидете на ClusterControl -> Изберете клъстер PostgreSQL -> Архивиране -> Създаване на архив.

Можете да изберете дали искате да създадете еднократно архивиране незабавно или да планирате ново архивиране. И така, нека изберем втората опция и да продължим.

Когато планирате архивиране, първо трябва да посочите график /честота. След това трябва да изберете метод за архивиране (pg_dumpall, pg_basebackup, pgBackRest), сървъра, от който ще бъде взето архивирането и където искате да съхранявате архива. Можете също да качите резервното ни копие в облака (AWS, Google или Azure), като активирате съответния бутон.

След това посочете използването на компресия, нивото на компресия, криптирането и периода на задържане за вашето резервно копие. Има още една функция, наречена „Проверка на архивиране“, която скоро ще видите по-подробно в тази публикация в блога.

Ако опцията „Качване на архивно копие в облака“ е била активирана, вие Ще видите тази стъпка, където трябва да изберете идентификационните данни в облака и да създадете или изберете S3 кофа, където да съхранявате архива. Трябва също да посочите периода на запазване.

Сега ще имате планираното архивиране в секцията ClusterControl Schedule Backups. За да покриете най-добрите практики, споменати по-рано, можете да планирате архивиране, за да го съхранявате във външен сървър (сървър ClusterControl) и в облака, и след това да планирате друго архивиране, за да го съхранявате локално в възела на базата данни за по-бързо възстановяване.

Възстановяване на резервно копие на Amazon EC2

След като архивирането приключи, можете да го възстановите, като използвате ClusterControl в секцията Архивиране.

Създаване на екземпляр на Amazon EC2

На първо място, за да го възстановите, ще трябва някъде да го направите, така че нека създадем основен екземпляр на Amazon EC2. Отидете на „Стартиране на екземпляр“ в конзолата за управление на AWS в секцията EC2 и конфигурирайте своя екземпляр.

Когато вашият екземпляр е създаден, ще трябва да копирате публичния SSH ключ от сървъра на ClusterControl.

Възстановяване на архива с помощта на ClusterControl

Сега имате новия екземпляр EC2, нека го използваме, за да възстановим архива там. За това във вашия ClusterControl отидете в секцията за архивиране (ClusterControl -> Изберете Cluster -> Backup) и там можете да изберете „Възстановяване на архива“ или директно „Възстановяване“ на архива, който искате да възстановите.

Имате три опции за възстановяване на архива. Можете да възстановите архива в съществуващ възел на база данни, да възстановите и проверите архива на самостоятелен хост или да създадете нов клъстер от архива. Тъй като искате да създадете възел със студен режим на готовност, нека използваме втората опция „Възстановяване и проверка на самостоятелен хост“.

Ще ви трябва специален хост (или VM), който не е част на клъстера, за да възстановите архива, така че нека използваме EC2 екземпляр, създаден за тази задача. ClusterControl ще инсталира софтуера и ще възстанови архива в този хост.

Ако опцията „Изключване на сървъра след възстановяване на архива“ е активирана, ClusterControl ще спре възела на базата данни след приключване на задачата за възстановяване и точно това ни трябва за това създаване в студен режим на готовност.

Можете да наблюдавате напредъка на архивирането в секцията ClusterControl Activity.

Използване на функцията ClusterControl Verify Backup

Архивът не е резервно копие, ако не може да се възстанови. Така че трябва да се уверите, че архивирането работи и да го възстановявате често в възела на студена готовност.

Тази функция за архивиране на ClusterControl Verify Backup е начин да се автоматизира поддръжката на възел в студен режим на готовност, като се възстановява скорошно архивиране, за да се поддържа възможно най-актуално, като се избягва задачата за архивиране на ръчно възстановяване. Нека видим как работи.

Като задачата „Възстановяване и проверка на самостоятелен хост“ ще изисква специален хост (или VM), който не е част от клъстера, за да възстанови архива, така че нека използваме същия EC2 екземпляр тук.

Функцията за автоматично потвърждаване на архивиране е налична за планираните резервни копия. Така че, отидете на ClusterControl -> Изберете клъстер PostgreSQL -> Архивиране -> Създаване на архив и повторете стъпките, които видяхте по-рано, за да планирате ново архивиране.

Във втората стъпка ще имате налична функцията „Проверка на архивиране“ за да го активирате.

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

Заключение

Ако имате ограничен бюджет, но изисквате висока наличност, можете да използвате възел на PostgreSQL в студен режим на готовност, който може да е валиден или не в зависимост от RTO и RPO на компанията. В този блог ви показахме как да планирате архивиране (в съответствие с вашата бизнес политика) и как да го възстановите ръчно. Показахме също как да възстановим автоматично архивирането в сървър със студен режим на готовност с помощта на ClusterControl, Amazon S3 и Amazon EC2.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да излезете от помощната програма за командния ред на PostgreSQLs (psql)

  2. Как PostgreSQL налага ограничението UNIQUE / какъв тип индекс използва?

  3. Основно наблюдение на PostgreSQL – част 1

  4. PostgreSQL:текущ брой редове за заявка „по минута“

  5. Връзка не съществува