В тази публикация в блога ние се гмуркаме в детайлите на настройката на поточно репликация (SR) в PostgreSQL. Репликацията на поточно предаване е основният градивен елемент за постигане на висока наличност във вашия PostgreSQL хостинг и се произвежда чрез изпълнение на конфигурация главен-подчинен.

Терминология Master-Slave

Главен/основен сървър

• Сървърът, който може да приема записи.
• Наричан още сървър за четене/запис.

Slave/Standby сървър

• Сървър, където данните се поддържат непрекъснато в синхрон с главния.
• Нарича се още резервен сървър или реплика.
• Сървър в топъл режим на готовност е този, към който не може да се свърже, докато не бъде повишен в главен сървър.
• За разлика от тях сървърът в режим на гореща готовност може да приема връзки и да обслужва заявки само за четене. До края на тази дискусия ще се съсредоточим само върху сървърите в режим на гореща готовност.

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

Репликация, базирана на доставка на WAL

Какво е WAL?

• WAL означава записване с предварителна запис.
• Това е регистрационен файл, в който всички модификации в базата данни се записват, преди да бъдат приложени/записани към файловете с данни.
• WAL се използва за възстановяване след срив на базата данни, като се гарантира целостта на данните.
• WAL се използва в системите за бази данни за постигане на атомарност и издръжливост.

Как се използва WAL за репликация?

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

Изпращане на регистрационни файлове на базата на файлове

• WAL регистрационните файлове се изпращат от главния към сървърите в режим на готовност, за да поддържат данните в синхрон.
• Мастерът може директно да копира регистрационните файлове в хранилище на резервния сървър или може да споделя хранилище със сървърите в режим на готовност.
• Един регистрационен файл на WAL може да съдържа до 16MB данни.
•  WAL файлът се изпраща само след като достигне този праг.
• Това ще доведе до забавяне на репликацията и също така ще увеличи шансовете за загуба на данни, ако главният срив и регистрационните файлове не са архивирани

Поточно предаване на WAL записи

• Частите от WAL записи се предават поточно от сървърите на бази данни, за да се поддържат синхронизирани данни.
• Сървърът в режим на готовност се свързва с главния, за да получи WAL парчетата.
• WAL записите се предават поточно, когато са генерирани.
• Стриймингът на WAL записи не трябва да чака WAL файлът да бъде попълнен.
• Това позволява на сървъра в режим на готовност да остане по-актуален, отколкото е възможно при доставка на регистрационни файлове, базирана на файлове.
• По подразбиране стрийминг репликацията е асинхронна, въпреки че поддържа и синхронна репликация.

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

Как да настроите поточно репликация?

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

Конфигурация на главния възел

• Инициализирайте базата данни на главния възел с помощта на помощната програма initdb.
• Създайте роля/потребител с привилегии за репликация, като изпълните командата по-долу. След като стартирате командата, можете да я проверите, като изпълните \du, за да ги изброите в psql.
  •   СЪЗДАВАНЕ НА ПОТРЕБИТЕЛ РЕПЛИКАЦИЯ ВХОД КРИПИРАНА ПАРОЛА ’’;
• Конфигурирайте свойства, свързани с поточно репликация в главния конфигурационен файл на PostgreSQL (postgresql.conf):
  

  # Възможните стойности са replica|minimal|logical wal_level =replica# се изисква за възможността pg_rewind, когато режимът на готовност излезе от синхрон с master wal_log_hints =on# задава максималния брой едновременни връзки от сървърите в режим на готовност. max_wal_senders =3 # Параметърът по-долу се използва, за да каже на главния да запази минималния брой # сегмента от WAL регистрационни файлове, така че да не бъдат изтрити, преди режимът на готовност да ги консумира. # всеки сегмент е 16MB wal_keep_segments =8 # Параметърът по-долу позволява връзка само за четене на възела, когато е в # роля в режим на готовност. Това се игнорира, когато сървърът работи като главен. hot_standby =включено

• Добавете запис за репликация във файла pg_hba.conf, за да разрешите връзки за репликация между сървърите:
  

  # Разрешаване на връзки за репликация от localhost, # от потребител с привилегията за репликация. # ТИП    БАЗА ДАННИ    ПОЛЗВАТЕЛ    АДРЕС    МЕТОД хост    репликация    repl_user    IPaddress(CIDR)    md5

• Рестартирайте услугата PostgreSQL на главния възел, за да влязат в сила промените.

Конфигурация на възел(и) в режим на готовност

• Създайте базовото архивиране на главния възел с помощта на помощната програма pg_basebackup и го използвайте като отправна точка за режим на готовност.
  

  # Обясняване на няколко опции, използвани за pg_basebackup помощната програма # -X опцията се използва за включване на необходимите регистрационни файлове на транзакциите (WAL файлове) в # архива. Когато посочите поток, това ще отвори втора връзка със сървъра # и ще започне стрийминг на дневника на транзакциите едновременно с стартирането на архивирането. # -c е опцията за контролна точка. Задаването му на бързо ще принуди контролната точка да бъде # създадена скоро. # -W принуждава pg_basebackup да поиска парола, преди да се свърже # към база данни. pg_basebackup -D <директория_данни>  -h <главен_хост> -X поток -c бързо -U repl_user -W

• Създайте конфигурационния файл за репликация, ако не присъства (той се създава автоматично, ако опцията -R е предоставена в pg_basebackup):
  

  # Указва дали да стартира сървъра като готовност. При поточно репликация, # този параметър трябва да е включен. standby_mode =‘on’# Указва низ за връзка, който се използва за свързване на сървъра в режим на готовност # с основния/главния. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Посочва възстановяването към определена времева линия. По подразбиране се възстановява по # същата времева линия, която е била текуща, когато е направено основното архивиране. # Задаване на това на последното възстановяване до най-новата времева линия, намерена # в архива, което е полезно в сървър в режим на готовност. recovery_target_timeline =„най-ново“

• Стартирайте режим на готовност.

Конфигурирането в режим на готовност трябва да се извърши на всички сървъри в режим на готовност. След като конфигурацията приключи и бъде стартиран режим на готовност, той ще се свърже с главния и ще започне стрийминг на регистрационни файлове. Това ще настрои репликацията и може да бъде проверено чрез изпълнение на SQL израза „SELECT * FROM pg_stat_replication; “.

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

Synchronous_commit трябва да е включено за синхронна репликация и това е по подразбиране. PostgreSQL предоставя много гъвкави опции за синхронно записване и може да се конфигурира на ниво потребител/база данни. Валидни стойности са както следва:

• Изключено – Завършването на транзакцията се потвърждава на клиента дори преди този запис на транзакцията действително да бъде изтрит в регистрационния файл WAL на този възел.
• Местни –  Отвързването на транзакциите се потвърждава от клиента само след като записът на транзакцията бъде изтрит в регистрационния файл WAL на този възел.
• Remote_write – Завършването на транзакцията се потвърждава на клиента само след като сървърът(ите), посочени от synchronous_standby_names, потвърди, че записът на транзакцията е бил записан в кеша на диска, но не непременно след изтриване в регистрационния файл на WAL.
• Включено – Завършването на транзакциите се потвърждава на клиента само след като сървърът(ите), определен(и) от synchronous_standby_names, потвърди, че записът на транзакцията се изтрива в регистрационния файл на WAL.
• Remote_apply – Завършването на транзакцията се потвърждава на клиента само след като сървърът(ите), определен(и) от synchronous_standby_names, потвърди, че записът на транзакцията се изтрива в регистрационния файл на WAL и се прилага към базата данни.

Задаването на synchronous_commit на изключено или локално в режим на синхронна репликация ще го накара да работи като асинхронен и може да ви помогне да постигнете по-добра производителност при запис. Това обаче ще има по-висок риск от загуба на данни и забавяне на четене на сървъри в режим на готовност. Ако е зададено на remote_apply, това ще осигури незабавна наличност на данни на сървърите в режим на готовност, но производителността на запис може да се влоши, тъй като трябва да се прилага на всички/споменатите сървъри в режим на готовност.

Можете да активирате режима на архивиране, ако планирате да използвате непрекъснато архивиране и възстановяване в момента. Въпреки че не е задължително за поточно репликация, активирането на режим на архивиране има допълнителни предимства. Ако режимът на архивиране не е включен, тогава трябва да използваме слотовете за репликация функция или се уверете, че wal_keep_segments стойността е зададена достатъчно висока в зависимост от натоварването.

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