როგორ შევქმენით სანდო PostgreSQL კლასტერი Patroni-ზე

დღეს სერვისების მაღალი ხელმისაწვდომობაა საჭირო ყოველთვის და ყველგან, არა მხოლოდ დიდ ძვირადღირებულ პროექტებში. ჯერ კიდევ გვხვდება დროებით მიუწვდომელი საიტები შეტყობინებით „ბოდიში, ტექნიკური სამუშაოები მიმდინარეობს“, მაგრამ, როგორც წესი, იწვევს დამამშვიდებელ ღიმილს. ამას დავუმატოთ სიცოცხლე ღრუბლებში, როცა დამატებითი სერვერის გასაშვებად საჭიროა მხოლოდ ერთი ზარი API-ზე და არ არის საჭირო "რკინის" ოპერაციაზე ფიქრი. და აღარ არსებობს გამართლება, თუ რატომ არ შეიქმნა კრიტიკული სისტემა საიმედოდ კლასტერული ტექნოლოგიებისა და ჭარბი რაოდენობით.

ჩვენ გეტყვით, რა გადაწყვეტილებები განვიხილეთ ჩვენს სერვისებში მონაცემთა ბაზების სანდოობის უზრუნველსაყოფად და რა მივიღეთ. პლუს დემო შორსმიმავალი დასკვნებით.

მემკვიდრეობა მაღალი ხელმისაწვდომობის არქიტექტურაში

ეს კიდევ უფრო კარგად ჩანს სხვადასხვა ღია კოდის სისტემების განვითარების კონტექსტში. მოთხოვნის გაზრდისას მოძველებულ გადაწყვეტილებებს უნდა დაემატებინა მაღალი ხელმისაწვდომობის ტექნოლოგიები. და მათი ხარისხი იცვლებოდა. შემდეგი თაობის გადაწყვეტილებები მაღალ ხელმისაწვდომობას აყენებს მათი არქიტექტურის ბირთვს. მაგალითად, MongoDB პოზიციონირებს კლასტერს, როგორც მის ძირითად გამოყენებას. კასეტური მასშტაბები ჰორიზონტალურად ხდება, რაც ამ DBMS-ის ძლიერი კონკურენტული უპირატესობაა.

მოდით დავუბრუნდეთ PostgreSQL-ს. ეს არის ერთ-ერთი უძველესი პოპულარული ღია კოდის პროექტი, რომლის პირველი გამოშვება მოხდა გასული საუკუნის 95-ე წელს. პროექტის გუნდი დიდი ხნის განმავლობაში არ თვლიდა მაღალ ხელმისაწვდომობას სისტემის მიერ გადასაჭრელ ამოცანად. ამრიგად, მონაცემთა ასლების შესაქმნელად რეპლიკაციის ტექნოლოგია ჩაშენებული გახდა მხოლოდ 8.2 ვერსიაში 2006 წელს, მაგრამ ეს იყო ფაილი (log shipping). 2010 წელს სტრიმინგის რეპლიკაცია გამოჩნდა 9.0 ვერსიაში და ეს არის კლასტერების მრავალფეროვანი შექმნის საფუძველი. ეს, ფაქტობრივად, ძალიან გასაკვირია მათთვის, ვინც PostgreSQL-ს ეცნობა Enterprise SQL-ის ან თანამედროვე NoSQL-ის შემდეგ - საზოგადოების სტანდარტული გადაწყვეტა არის უბრალოდ სამაგისტრო-რეპლიკა წყვილი სინქრონული ან ასინქრონული რეპლიკაციით. ამავდროულად, დრენაჟში ოსტატის გადართვა ხდება ხელით, ასევე შემოთავაზებულია კლიენტების გადართვის საკითხის დამოუკიდებლად გადაწყვეტა.

როგორ გადავწყვიტეთ გაგვეკეთებინა სანდო PostgreSQL და რა ავირჩიეთ ამისათვის

თუმცა, PostgreSQL არ გახდებოდა ასეთი პოპულარული, რომ არა დიდი რაოდენობით პროექტები და ხელსაწყოები, რომლებიც ხელს უწყობენ შეცდომისადმი ტოლერანტული გადაწყვეტის შექმნას, რომელიც არ საჭიროებს მუდმივ ყურადღებას. ღრუბელში Mail.ru Cloud Solutions (MCS) DBaaS-ის გაშვების დღიდან ხელმისაწვდომია ერთჯერადი PostgreSQL სერვერები და მასტერ-რეპლიკა წყვილები ასინქრონული რეპლიკაციით.

ბუნებრივია, ჩვენ გვინდოდა გაგვეადვილებინა ცხოვრება ყველასთვის და ხელმისაწვდომი გაგვეყენებინა PostgreSQL ინსტალაცია, რომელიც შეიძლება გახდეს მაღალი ხელმისაწვდომობის სერვისების საფუძველი, რომლებსაც არ მოუწევთ მუდმივი მონიტორინგი და ღამით გაღვიძება გადართვისთვის. ამ სეგმენტში არის როგორც ძველი დადასტურებული გადაწყვეტილებები, ასევე ახალი კომუნალური საშუალებების თაობა, რომელიც იყენებს უახლეს განვითარებას.

დღეს, მაღალი ხელმისაწვდომობის პრობლემა ემყარება არა დათქმას (ეს ცხადია), არამედ კონსენსუსზე - ლიდერის არჩევის ალგორითმზე (ლიდერის არჩევნები). ყველაზე ხშირად, დიდი ავარიები ხდება არა სერვერების ნაკლებობის გამო, არამედ კონსენსუსის პრობლემების გამო: ახალი ლიდერი არ გამოვიდა, ორი ლიდერი გამოჩნდა სხვადასხვა მონაცემთა ცენტრში და ა.შ. ამის მაგალითია Github MySQL კლასტერზე ავარია – წერდნენ ისინი სიტყვიერი პოსტმოკვდა.

მათემატიკური საფუძველი ამ საკითხში ძალიან სერიოზულია. ერთი მხრივ, იქ CAP თეორემა, რომელიც აწესებს თეორიულ შეზღუდვებს HA ამონახსნების აგების შესაძლებლობებზე, მეორეს მხრივ, მათემატიკურად დადასტურებულ ალგორითმებს კონსენსუსის დასადგენად, მაგ. პაქსი и რაფტინგი. ამის საფუძველზე საკმაოდ პოპულარულია DCS (დეცენტრალიზებული კონსენსუსის სისტემები) - Zookeeper, etcd, Consul. ამიტომ, თუ გადაწყვეტილების მიღების სისტემა მუშაობს დამოუკიდებლად დაწერილ ზოგიერთ ალგორითმზე, ძალიან ფრთხილად უნდა იყოთ. უზარმაზარი რაოდენობის სისტემების გაანალიზების შემდეგ, ჩვენ გადავწყვიტეთ Patroni, ღია კოდის სისტემა, რომელიც ძირითადად Zalando-ს მიერ არის შემუშავებული.

ლირიკულ დიგრესიად ვიტყვი, რომ ჩვენ ასევე განვიხილეთ მულტიმასტერ გადაწყვეტილებები, ანუ კლასტერები, რომლებიც შეიძლება ჰორიზონტალურად იყოს მასშტაბირებული ჩასაწერად. თუმცა, ორი ძირითადი მიზეზის გამო, გადავწყვიტეთ არ გაგვეკეთებინა ასეთი კლასტერი. პირველ რიგში, ასეთ გადაწყვეტილებებს აქვს მაღალი სირთულე და, შესაბამისად, მეტი დაუცველობა. რთული იქნება ყველა შემთხვევისთვის სტაბილური გამოსავლის მიღება. მეორეც, ამ შემთხვევაში, PostgreSQL წყვეტს სუფთა (მშობლიური), ზოგიერთი ფუნქცია მიუწვდომელი იქნება, ზოგიერთ აპლიკაციას შეიძლება ჰქონდეს ფარული შეცდომები ოპერაციის დროს.

პატრონი

როგორ მუშაობს პატრონი? დეველოპერებმა არ გამოიგონეს ბორბალი და შესთავაზეს ერთ-ერთი დადასტურებული DCS გადაწყვეტის გამოყენება, როგორც საფუძველი. მის წყალობაზეა ყველა საკითხი კონფიგურაციების სინქრონიზაციის, ლიდერის არჩევისა და კვორუმის შესახებ. ჩვენ ამისთვის ავირჩიეთ etcd.

შემდეგი, Patroni ეხება PostgreSQL-ის ყველა პარამეტრის და რეპლიკაციის პარამეტრების სწორ გამოყენებას, ასევე ბრძანებების შესრულებას გადართვისა და წარუმატებლობისთვის (ანუ მასტერის რეგულარულ და არანორმალური გადართვა). კერძოდ, MCS ღრუბელში შეგიძლიათ შექმნათ კლასტერი ოსტატისგან, სინქრონული რეპლიკადან და ერთი ან მეტი ასინქრონული რეპლიკისგან. სინქრონული ასლის არსებობა უზრუნველყოფს მონაცემთა უსაფრთხოებას მინიმუმ 2 სერვერზე და სწორედ ეს რეპლიკა იქნება მთავარი „მასტერ კანდიდატი“.

ვინაიდან etcd განლაგებულია იმავე სერვერებზე, ოპტიმალური კვორუმისთვის რეკომენდებულია 3 ან 5 სერვერი. ასეთი კლასტერი კითხვისთვის ჰორიზონტალურად მასშტაბებს (ზემოთ დავწერე სკალირების შესახებ წერისთვის). თუმცა, გაითვალისწინეთ, რომ ასინქრონული რეპლიკა, როგორც წესი, ჩამორჩება, განსაკუთრებით მძიმე დატვირთვის დროს.

ასეთი რეპლიკების გამოყენება წასაკითხად (ცხელი ლოდინი) გამართლებულია საანგარიშო ან ანალიტიკური ამოცანებისთვის და განტვირთავს მთავარ სერვერს.

თუ გსურთ თავად გააკეთოთ ასეთი კლასტერი, მაშინ დაგჭირდებათ:

• მოამზადეთ 3 ან მეტი სერვერი, დააკონფიგურიროთ IP მისამართები და ფაირვოლ-ის წესები მათ შორის;
• დააინსტალირეთ პაკეტები etcd, Patroni, PostgreSQL სერვისებისთვის;
• etcd კლასტერის დაყენება;
• პატრონის სერვისის კონფიგურაცია PostgreSQL-თან მუშაობისთვის.

ანუ, მთლიანობაში, თქვენ უნდა სწორად შეადგინოთ ათეული კონფიგურაციის ფაილი და არსად არ დაუშვათ შეცდომა. ამისათვის თქვენ აუცილებლად უნდა გამოიყენოთ კონფიგურაციის მართვის ინსტრუმენტი, როგორიცაა Ansible, მაგალითად. თუმცა, ჯერ კიდევ არ არის ხელმისაწვდომი TCP ბალანსერი. მისი დამზადება ცალკე საქმეა.

ვისაც მზა კლასტერი სჭირდება, მაგრამ არ სურს ამ ყველაფერში ჩხუბი, შევეცადეთ გაგვემარტივოთ ცხოვრება და ჩვენს ღრუბელში შევქმენით მზა კლასტერი პატრონზე, შეგიძლიათ უფასოდ გამოსცადოთ. გარდა თავად კლასტერისა, ჩვენ გავაკეთეთ:

• TCP ბალანსერი; სხვადასხვა პორტებზე ის ყოველთვის მიუთითებს მიმდინარე მთავარზე, სინქრონულ ან ასინქრონულ რეპლიკაზე, შესაბამისად;
• API აქტიური Patroni master-ის გადასართავად.

მათი ქვეკლასირება შესაძლებელია როგორც MCS ღრუბლოვანი API-ის, ასევე ვებ კონსოლის მეშვეობით.

დემო

MCS ღრუბელში PostgreSQL კლასტერის შესაძლებლობების შესამოწმებლად, ვნახოთ, როგორ იქცევა ცოცხალი აპლიკაცია DBMS-თან დაკავშირებული პრობლემების შემთხვევაში.

ქვემოთ მოცემულია აპლიკაციის კოდი, რომელიც აღწერს ხელოვნურ მოვლენებს და აცნობებს მათ ეკრანზე. შეცდომის შემთხვევაში, ის შეატყობინებს ამას და გააგრძელებს მუშაობას ციკლურად, სანამ არ გავაჩერებთ Ctrl + C კომბინაციით.

from __future__ import print_function

from datetime import datetime
from random import randint
from time import sleep
import psycopg2


def main():
    try:
        connection = psycopg2.connect(user = "admin",
                                      password = "P@ssw0rd",
                                      host = "89.208.87.38",
                                      port = "5432",
                                      database = "myproddb")

        cursor = connection.cursor()
        cursor.execute("SELECT version();")
        record = cursor.fetchone()
        print("Connection opened to", record[0])

        cursor.execute(
            "INSERT INTO log VALUES ({});".format(randint(1, 10000)))
        connection.commit()
        cursor.execute("SELECT COUNT(event_id) from log;")
        record = cursor.fetchone()
        print("Logged a value, overall count: {}".format(record[0]))
    except Exception as error:
        print ("Error while connecting to PostgreSQL", error)
    finally:
        if connection:
            cursor.close()
            connection.close()
            print("Connection closed")


if __name__ == '__main__':
    try:
        while True:
            try:
                print(datetime.now())
                main()
                sleep(3)
            except Exception as e:
                print("Caught error:n", e)
                sleep(1)
    except KeyboardInterrupt:
        print("exit")

აპლიკაციას სჭირდება PostgreSQL სამუშაოდ. მოდით შევქმნათ კლასტერი MCS ღრუბელში API-ის გამოყენებით. ჩვეულებრივ ტერმინალში, სადაც OS_TOKEN ცვლადი შეიცავს API-ზე წვდომის ნიშანს (შეიძლება მიიღოთ openstack token issue ბრძანებით), ჩვენ ჩავწერთ ბრძანებებს:

შექმენით კლასტერი:

cat <<EОF > pgc10.json
{"cluster":{"name":"postgres10","allow_remote_access":true,"datastore":{"type":"postgresql","version":"10"},"databases":[{"name":"myproddb"}],"users":[{"databases":[{"name":"myproddb"}],"name":"admin","password":"P@ssw0rd"}],"instances":[{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}},{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}},{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}}]}}
EOF

curl -s -H "X-Auth-Token: $OS_TOKEN" 
-H 'Accept: application/json' 
-H 'Content-Type: application/json' 
-d @pgc10.json https://infra.mail.ru:8779/v1.0/ce2a41bbd1434013b85bdf0ba07c770f/clusters

როდესაც კლასტერი გადადის ACTIVE სტატუსზე, ყველა ველი მიიღებს მიმდინარე მნიშვნელობებს - კლასტერი მზად არის.

GUI-ში:

შევეცადოთ დაკავშირება და შევქმნათ ცხრილი:

psql -h 89.208.87.38 -U admin -d myproddb
Password for user admin:
psql (11.1, server 10.7)
Type "help" for help.

myproddb=> CREATE TABLE log (event_id integer NOT NULL);
CREATE TABLE
myproddb=> INSERT INTO log VALUES (1),(2),(3);
INSERT 0 3
myproddb=> SELECT * FROM log;
 event_id
----------
        1
        2
        3
(3 rows)

myproddb=>

აპლიკაციაში ჩვენ განვსაზღვრავთ მიმდინარე პარამეტრებს PostgreSQL-თან დასაკავშირებლად. ჩვენ დავაზუსტებთ TCP ბალანსერის მისამართს, რითაც აღმოვფხვრით მასტერის მისამართზე ხელით გადართვის საჭიროებას. მოდით გავუშვათ იგი. როგორც ხედავთ, მოვლენები წარმატებით არის შესული მონაცემთა ბაზაში.

დაგეგმილი სამაგისტრო გადართვა

ახლა მოდით შევამოწმოთ ჩვენი აპლიკაციის მოქმედება ოსტატის დაგეგმილი გადართვის დროს:

ჩვენ ვუყურებთ აპლიკაციას. ჩვენ ვხედავთ, რომ აპლიკაცია ნამდვილად წყდება, მაგრამ ამას მხოლოდ რამდენიმე წამი სჭირდება, ამ კონკრეტულ შემთხვევაში მაქსიმუმ 9.

ავტოსაგზაო შემთხვევა

ახლა ვცადოთ ვირტუალური მანქანის, ამჟამინდელი ოსტატის დაცემის სიმულაცია. ვირტუალური მანქანის უბრალოდ გამორთვა შესაძლებელი იქნება ჰორიზონტის ინტერფეისის საშუალებით, მხოლოდ ეს იქნება რეგულარული გამორთვა. ასეთ გადართვას დაამუშავებს ყველა სერვისი, მათ შორის პატრონი.

ჩვენ გვჭირდება არაპროგნოზირებადი გამორთვა. ამიტომ, მე ვთხოვე ჩვენს ადმინისტრატორებს სატესტო მიზნებისთვის, რომ გამორთონ ვირტუალური მანქანა - ამჟამინდელი მასტერი - არანორმალური გზით.

პარალელურად, ჩვენი აპლიკაცია განაგრძობდა მუშაობას. ბუნებრივია, ოსტატის ასეთი გადაუდებელი გადართვა არ შეიძლება შეუმჩნეველი დარჩეს.

2019-03-29 10:45:56.071234
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 453
Connection closed
2019-03-29 10:45:59.205463
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 454

Connection closed
2019-03-29 10:46:02.661440
Error while connecting to PostgreSQL server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

Caught error:
 local variable 'connection' referenced before assignment
……………………………………………………….. - здесь какое-то количество ошибок
2019-03-29 10:46:30.930445
Error while connecting to PostgreSQL server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

Caught error:
 local variable 'connection' referenced before assignment
2019-03-29 10:46:31.954399
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 455
Connection closed
2019-03-29 10:46:35.409800
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 456
Connection closed
^Cexit

როგორც ხედავთ, აპლიკაციამ შეძლო მუშაობის გაგრძელება 30 წამზე ნაკლებ დროში. დიახ, სერვისის მომხმარებელთა გარკვეულ რაოდენობას ექნება დრო, რომ შეამჩნიონ პრობლემები. თუმცა, ეს არის სერვერის სერიოზული ავარია, ეს ასე ხშირად არ ხდება. ამავდროულად, ადამიანს (ადმინისტრატორს) ძნელად ექნებოდა დრო ასე სწრაფად რეაგირებისთვის, თუ იგი მზად არ იჯდა კონსოლში გადართვის სკრიპტით.

გამოყვანის

მეჩვენება, რომ ასეთი კლასტერი უზარმაზარ უპირატესობას აძლევს ადმინისტრატორებს. სინამდვილეში, მონაცემთა ბაზის სერვერების სერიოზული ავარია და წარუმატებლობა არ იქნება შესამჩნევი განაცხადისთვის და, შესაბამისად, მომხმარებლისთვის. თქვენ არ გჭირდებათ რაღაცის დაჩქარება და გადართვა დროებით კონფიგურაციებზე, სერვერებზე და ა.შ. და თუ ასეთი გამოსავალი გამოიყენება როგორც მზა სერვისი ღრუბელში, მაშინ არ იქნება საჭირო დროის დახარჯვა მის მომზადებაზე. შეგიძლიათ გააკეთოთ რაღაც უფრო საინტერესო.

წყარო: www.habr.com