Îro, ne tenê di projeyên giranbiha yên mezin de, hebûna karûbaran her dem û li her deverê hewce ye. Malperên demkî ne berdest ên bi peyama "Bibore, lênêrînê berdewam e" hîn jî têne dîtin, lê bi gelemperî dibe sedema bişirînek nerazî. Werin em vê jiyanê di ewran de zêde bikin, dema ku hûn serverek zêde bidin destpêkirin hûn tenê hewceyê yek bangek API-yê ne, û hûn ne hewce ne ku li ser operasyona "hardware" bifikirin. Û êdî tu hincet nînin ku çima pergalek krîtîk bi pêbawerî bi karanîna teknolojiyên komê û zêdebûnê nehatiye çêkirin.
Em ê ji we re vebêjin ka me çi çareserî fikirî da ku pêbaweriya databasan di karûbarên xwe de piştrast bike û em gihîştine çi. Zêdeyî demoyek bi encamên dûr.
Mîras di Mîmariya Berdestbûna Bilind de
Ev di çarçoveya pêşkeftina pergalên cihêreng ên çavkaniya vekirî de hîn çêtir tê dîtin. Gava ku daxwaz zêde bû, çareseriyên mîras neçar bûn ku teknolojiyên hebûna bilind zêde bikin. Û kalîteya wan cûda bû. Çareseriyên nifşê paşîn hebûna bilind di bingeha mîmariya xwe de cih digirin. Mînakî, MongoDB wekî doza karanîna wê ya bingehîn kom dike. Kom bi horizontî pîvan dibe, ku ev yek avantajek pêşbaziyek bihêz a vê DBMS-ê ye.
Ka em vegerin PostgreSQL. Ev yek ji kevintirîn projeyên çavkaniya vekirî ya populer e, ku yekem serbestberdana wê di sala 95-an a sedsala borî de pêk hat. Demek dirêj, tîmê projeyê hebûna zêde wekî pirsgirêkek ku pêdivî ye ku ji hêla pergalê ve were çareser kirin nahesibîne. Ji ber vê yekê, teknolojiya dubarekirinê ya ji bo afirandina kopiyên daneyan tenê di guhertoya 8.2-ê de di sala 2006-an de hatî çêkirin, lê ew pel-based bû (şûştina têketinê). Di sala 2010-an de, guhertoya 9.0-ê dubarekirina streaming destnîşan kir, û ew bingeha afirandina cûrbecûr koman e. Ev, bi rastî, ji kesên ku piştî Enterprise SQL an NoSQL-ya nûjen bi PostgreSQL re nas dikin pir ecêb e - çareseriya standard ji civatê bi tenê cotek master-replica ye ku bi dubarekirina hevdemî an asynchronous e. Di heman demê de, di stokê de, guheztina masterê bi destan tê kirin, û pirsgirêka guheztina xerîdaran jî tê pêşniyar kirin ku serbixwe were çareser kirin.
Me çawa biryar da ku PostgreSQL pêbawer çêbikin û me ji bo vê yekê çi hilbijart
Lêbelê, PostgreSQL dê ew qas populer nebûya heke hejmareke mezin ji proje û amûrên ku alîkariya avakirina çareseriyek xelet-tolerant ku hewcedariya domdar ne hewce dike tunebûna. Di ewr de (MCS) Pêşkêşkerên PostgreSQL yên yekane û cotên master-replica yên bi repplication asynchronous ji destpêka DBaaS ve hatine peyda kirin.
Bi xwezayî, me xwest ku em jiyanê ji her kesî re hêsantir bikin û sazkirinek PostgreSQL peyda bikin ku dikare bibe bingehek ji bo karûbarên pir berdest, bêyî ku bi domdarî çavdêrî bikin û bi şev şiyar bibin da ku veguherînê bikin. Di vê beşê de hem çareseriyên îsbatkirî yên kevn û hem jî nifşek karûbarên nû hene ku pêşkeftinên herî dawî bikar tînin.
Îro, pirsgirêka hebûna bilind ne li ser zêdebûnê ye (ku bê gotin), lê li ser lihevhatinê - algorîtmaya hilbijartina Rêbertî. Bi gelemperî, qezayên mezin ne ji ber kêmbûna serveran, lê ji ber pirsgirêkên lihevhatinê diqewimin: serokek nû nehatiye hilbijartin, du serok li navendên daneyên cihêreng xuya bûne, hwd. Mînak - qezayek li ser komek Github MySQL - wan nivîsand .
Di vê mijarê de bingeha matematîkî pir giran e. Li aliyekî, heye , ku sînorkirinên teorîk li ser îmkanên avakirina çareseriyên HA ferz dike, ji hêla din ve, algorîtmayên matematîkî yên îsbatkirî yên ji bo destnîşankirina lihevkirinê, wek mînak и . Li ser vê bingehê, DCS (pergalên lihevhatina nenavendî) pir populer hene - Zookeeper, etcd, Konsul. Ji ber vê yekê, heke pergala biryargirtinê li ser cûreyek algorîtmayek, ku serbixwe hatî nivîsandin, tevdigere, divê hûn wê bi hişyariyek zehf derman bikin. Piştî analîzkirina hejmareke mezin a pergalan, em li ser Patroni, pergalek çavkaniyek vekirî bi piranî ji hêla Zalando ve hatî pêşve xistin, rûniştin.
Wekî dûrketinek lîrîk, ez ê bibêjim ku me çareseriyên pir-master jî dihesibîne, ango komên ku ji bo tomarkirinê dikarin bi horizontî werin pîvandin. Lêbelê, ji ber du sedemên sereke wan biryar da ku komek wusa ava nekin. Ya yekem, çareseriyên weha xwedan tevliheviyek mezin û, li gorî, bêtir qelsî ne. Dê zehmet be ku ji bo hemî bûyeran çareseriyek bi îstîqrar were çêkirin. Ya duyemîn, di vê rewşê de PostgreSQL ji safîbûna (xwemalî) namîne, hin fonksiyon dê ne berdest bin, û dibe ku hin serîlêdan di dema xebatê de xeletiyên veşartî hebin.
Patroni
Ji ber vê yekê Patroni çawa dixebite? Pêşdebiran teker ji nû ve îcad nekirin û pêşniyar kirin ku yek ji çareseriyên DCS-ê yên pejirandî wekî bingeh bikar bînin. Hemî mijarên bi hevdemkirina veavakirinan, hilbijartina serok û quorumê ji wî re têne hiştin. Me ji bo vê etcd hilbijart.
Dûv re, Patroni bi sepana rast a hemî mîhengan li ser PostgreSQL û mîhengên dubarekirinê, û hem jî bi cîbicîkirina fermanan li ser veguheztin û têkçûn (ango, guheztina birêkûpêk û awarte ya masterê) re mijûl dibe. Bi taybetî di ewrê MCS de, hûn dikarin komek master, kopiyek hevdem û yek an çend kopiyên asynchronous biafirînin. Hebûna kopiyek hevdemî ewlehiya daneyan li ser kêmî 2 pêşkêşkeran misoger dike, û ew kopiyek e ku dê bibe "berendamê sereke".
Ji ber ku etcd li ser heman serveran tête bicîh kirin, ji bo quoruma herî baş jimara pêşkêşkeran 3 an 5 e. Komek wusa ji bo xwendinê bi horizontî diheje (min li jor li ser pîvandina ji bo nivîsandinê nivîsî). Lêbelê, hay ji xwe hebin ku kopiyên asynchronous bi taybetî di bin bargiraniyên bilind de meyldar in ku dereng bimînin.
Bikaranîna kopiyên xwendinê yên weha (standby germ) ji bo raporkirin an karên analîtîk rastdar e û barê servera masterê sivik dike.
Heke hûn dixwazin bi xwe komek wusa çêbikin, hûn ê hewce bibin:
- 3 an bêtir pêşkêşkeran amade bikin, navnîşana IP-ê û qaîdeyên dîwarê di navbera wan de mîheng bikin;
- ji bo karûbarên etcd, Patroni, PostgreSQL pakêtan saz bikin;
- mîhengê etcd cluster;
- karûbarê patroni mîheng bikin ku bi PostgreSQL re bixebite.
Ango, bi tevahî, hûn hewce ne ku bi dehan pelên mîhengê rast berhev bikin û li cîhek xeletî nekin. Ji bo vê yekê divê hûn bê guman amûrek rêveberiya vesazkirinê, wekî mînak Ansible, bikar bînin. Lêbelê, hîn jî balansek TCP-ya pir berdest tune. Çêkirina wê karekî cuda ye.
Ji bo kesên ku hewceyê komikek amade ne, lê naxwazin bi van hemîyan re biqelînin, me hewl da ku jiyanê hêsan bikin û li ser Patroni di ewrê xwe de komek amade çêkir, hûn dikarin wê belaş biceribînin. Ji bilî komê bixwe, me kir:
- balansa TCP; li ser lîmanên cihêreng ew her gav bi rêzê li ser masterê heyî, hevdem an asynchronous nîşan dide;
- API ji bo guheztina masterê Patroni çalak.
Ew dikarin bi navgîniya MCS cloud API û konsolê malperê ve werin gihîştin.
Demo
Ji bo ceribandina kapasîteyên komek PostgreSQL di ewrê MCS de, em bibînin ka serîlêdanek zindî di bûyera pirsgirêkên DBMS-ê de çawa tevdigere.
Li jêr koda serîlêdanek heye ku dê bûyerên sûnî tomar bike û wê li ser ekranê rapor bike. Di rewşên xeletiyan de, ew ê vê yekê rapor bike û xebata xwe bi rengek bidomîne heya ku em wê bi kombînasyona Ctrl + C rawestînin.
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")
Serlêdan hewce dike ku PostgreSQL bixebite. Werin em bi karanîna API-ê di ewrê MCS de komek biafirînin. Di termînalek birêkûpêk de, ku guhêrbar OS_TOKEN nîşanek ji bo gihîştina API-yê vedihewîne (dibe ku bi fermana pirsgirêka token openstack were wergirtin), em ê fermanên jêrîn binivîsin:
Komek ava bikin:
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
Dema ku kom di statûya ACTIVE de biguhere, hemî zevî dê nirxên heyî bistînin - kom amade ye.
Di GUI de:
Ka em hewl bidin ku bi hev ve girêbidin û tabloyek çêbikin:
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=>
Di serîlêdanê de em ê mîhengên heyî yên ji bo girêdana PostgreSQL destnîşan bikin. Em ê navnîşana balansa TCP-ê diyar bikin, bi vî rengî hewcedariya guheztina bi destan li navnîşana sereke ji holê rakin. Ka em wê bidin destpêkirin. Wekî ku hûn dibînin, bûyer bi serfirazî di databasê de têne tomar kirin.
Guhestina masterê ya plankirî
Naha em werin xebitandina serîlêdana xwe di dema guhezek masterê ya plansazkirî de ceribandin:
Em serlêdanê dişopînin. Em dibînin ku serîlêdan bi rastî qut bûye, lê ew tenê çend saniyeyan digire, di vê rewşa taybetî de, herî zêde 9.
qezaya otomobîlê
Naha em hewl bidin ku têkçûna makîneyek virtual, masterê heyî simule bikin. Hûn dikarin bi navgîniya navgîniya Horizon-ê ve makîneya virtual veqetînin, lê ev ê girtina birêkûpêk be. Veguheztinek wusa dê ji hêla hemî karûbaran ve, tevî Patroni, were pêvajo kirin.
Pêdiviya me bi qutbûnek nediyar heye. Ji ber vê yekê, min ji rêveberên me xwest ku ji bo mebestên ceribandinê makîneya virtual - masterê heyî - bi rengek ne-standard biqewirînin.
Di heman demê de serlêdana me berdewam kir. Bi xwezayî, guheztinek wusa acîl a master nikare ji nedîtî ve were.
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
Wekî ku hûn dibînin, sepanê karîbû di kêmtirî 30 çirkeyan de xebata xwe bidomîne. Erê, hejmarek ji bikarhênerên karûbarê dê dem hebe ku pirsgirêkan bibînin. Lêbelê, ev têkçûnek ciddî ya serverê ye; ev pir caran çênabe. Di vê rewşê de, kesek (rêveber) çu carî wextê wê tunebû ku bi vî rengî zû bertek nîşan bide, heya ku ew di konsolê de amade ne bi senaryoya guheztinê rûne.
encamê
Ji min re xuya dike ku komek wusa ji bo rêveberan avantajek mezin peyda dike. Di rastiyê de, têkçûn û têkçûnên ciddî yên serverên databasê dê ji serîlêdanê û, li gorî, ji bikarhêner re neyên berçav. Hûn neçar in ku tiştek bi lez rast bikin û veguherînin mîhengên demkî, pêşkêşker, hwd. Û heke çareseriyek wusa wekî karûbarek amade di ewr de were bikar anîn, wê hingê hûn ê hewce nebin ku wextê xwe winda bikin amadekirina wê. Dê gengaz be ku meriv tiştek balkêştir bike.
Source: www.habr.com
