Botrus Failover PostgreSQL + Patroni. Exsequendam experientiam

In hoc articulo referam tibi quomodo accessimus ad eventum PostgreSQL culpae tolerantiae, cur magni momenti nobis factum est, et quid tandem factum est.

Plurimum oneratum habemus servitium: 2,5 decies centena users per orbem, 50K+ active utentes cotidie. Servitores in una Hiberniae regione sita sunt: ​​100+ servitores diversi constanter in operatione, 50 fere cum databases sunt.

Totum backend est magna applicationis monolithic status Javae, quae nexum interretialem cum client pervicax conservat. Cum plures utentes simul in eadem tabula laborant, omnes mutationes in tempore reali vident, quia omnem mutationem datorum commemoramus. Petitiones circiter 10K per secundam nostris databases habemus. Ad apicem oneris in Redis petitiones 80-100K secundo scribimus.

Quare nos switched ex Redis ad PostgreSQL

Initio, officium nostrum cum Redis operatum est, repositionis key-valoris, quae omnia notitias in RAM ministrantis reponit.

Pros of Redis:

1. Princeps celeritatis responsio, quod omnia in memoria reponuntur;
2. Dapibus commodo ac replicatio.

Cons de Redis pro nobis;

1. Verae res nullae sunt. Eos imitari conati sumus in gradu applicationis nostri. Infeliciter, hoc bene non semper laboravit et scripturam valde implicatam requirebat.
2. Quantitas data finitur per quantitatem memoriae. Cum copia notitiarum crescit, memoria crescet, et in fine incurramus in notas instantiae selectae, quae in AWS requiruntur intermissione servitutis nostrae ad mutandam instantiam generis.
3. Necesse est ut humili gradu late- entiam constanter servet, quia Plurimum petitionum habemus numerum. Optima latency planities nobis est 17-20 ms. In gradu 30-40 ms, longa responsionibus ad applicationem petitionum ac servitii degradationis consequimur. Dolendum sane, hoc nobis mense Septembri 2018 factum est, cum una ex instantiis cum Redis ob aliquam causam latency recepit quae 2 temporibus solito altior erat. Ad problema solvendum, ministerium in medio die laborantis cessavimus ad conservationem sine clausula et instantia problematica Redis substituimus.
4. Facile est notitias incongruas etiam cum minoribus erroribus in codice accipere et multum temporis scribere in codice scribendo ad illam notam figere.

Nos incommoditates consideramus et intelleximus nos ad aliquid commodius moveri oportere, cum communibus negotiis et minus dependentiae a latendo. Investigationes nostras fecimus, multas optiones enucleavimus et PostgreSQL elegerunt.

Ad novum database per 1,5 annos nunc movebamus et tantum particulam notitiarum transtulimus, ita nunc simul cum Redis et PostgreSQL laboramus. Plura de gradibus movendi et mutandi notitia inter databases scriptum est articulus a collega meo.

Cum primum movere coepimus, nostra applicatio recta cum datorum opera elaboravit et ad Redis et PostgreSQL dominum accesserunt. Botrus PostgreSQL in magistro et replica cum replicatione asynchrono constabat. Hoc est quod database workflow visi sunt:

Exsequens PgBouncer

Dum nos moveremus, productum etiam elaborandum est: numerus utentium et numerus ministrantium qui operati sunt PostgreSQL auctus est et iunctio currere coepimus. PostgreSQL processum separatum pro unoquoque nexu creat et opes consumit. Numerum nexuum augere potes usque ad certum punctum, alioquin facultas datorum optimam operam non faciet. Optio idealis in tali condicione esset procuratorem nexum deligere qui ante datorum stabitur.

Duas optiones pro nexu procuratoris habuimus: Pgpool et PgBouncer. Sed primum non sustinet transactionalem modum operandi cum datorum, sic nos elegimus PgBouncer.

Schema operis sequentis conformavimus: applicatio nostra accedit ad unum PgBouncer, post quem magistri PostgreSQL sunt, et post unumquemque dominum est una replica cum replicatione asynchrona.


Simul, non potuimus totam copiam notitiarum in PostgreSQL reponere et celeritas operandi cum datorum magna nobis erat, sic postgreSQL in gradu applicationis sarciendo incepimus. Consilium supra descriptum hoc relative opportunum est: cum novam postgreSQL testa addito, satis est configurationem PgBouncer renovare et applicatio cum testa nova statim operari potest.

PgBouncer Culpa Tolerantia

Quae res usque ad unicam instantiam PgBouncer mortuus est. In AWS sumus, ubi omnes instantiae in ferramentis inducuntur quae periodice intereunt. In talibus casibus, instantia simpliciter movet ad nova ferramenta et iterum operatur. Hoc cum PgBouncer factum est, sed pervulgatum factum est. Effectus huius ruinae fuit ut ministerium nostrum per 25 minutas unavailable. Talibus adiunctis, AWS suadet utens redundantia in parte utentis, quod non tunc efficiendum.

Post hoc, serio cogitavimus de culpa tolerantiae uvarum PgBouncer et PostgreSQL, quia consimilis condicio iterum accidere potuit cum aliqua instantia in ratione nostra AWS.

PgBouncer culpae tolerantiae schema aedificavimus hoc modo: omnes applicationes servientes ad onera Network Librarius accesserunt, post quem duo PgBouncers sunt. Singuli PgBouncers ad eundem dominum PostgreSQL cuiuslibet testae spectat. Si res cum fragore instantiae AWS repetit, omnis negotiatio per alium PgBouncer directa est. Network Load Balancer culpa tolerantiae praebetur ab AWS.

Quae res te permittit ut facile novos servos PgBouncer addas.

Creando PostgreSQL Failover Botri

Cum hanc quaestionem solvendo varias optiones consideravimus: deficientia auto-scripta, repmgr, AWS RDS, Patroni.

Scripta auto-scripta

Possunt domini opus monitori et, si deficit, imaginem magistro promovere et configurationem PgBouncer renovare.

Commoda huius accessionis sunt maxima simplicitas, quod scribis te ipsum et intelligas prorsus quomodo operantur.

cons:

• Non potuit dominus perire, sed retis defectum poterat esse. Defectus huius ignarus, imaginem domino promovebit, et dominus vetus laborabit. Quam ob rem duos ministros in domino munus habebimus nec sciemus uter eorum recentissima notitia habeatur. Qui locus est et aluminis cerebrum;
• Sine responso relicti sumus. In nostra configuratione est dominus et una replica, post mutans imaginem ad dominum promovetur et non habemus amplius replicas, sic manuale adiciamus novam imaginem;
• Opus addito vigilantia operandi deficientis, et habemus 12 shards PostgreSQL, quod ope monitoris 12 botri opus est. Cum numerum shardorum augere, meminisse debes etiam defectionem renovare.

A deficientis scriptoris sui ipsius aspectus perplexus est et subsidium non leve requirit. Cum uno botro PostgreSQL, optio simplicissima haec erit, sed non scalae, ideo nobis non convenit.

Repmgr

Replicatio Procurator pro racemis PostgreSQL, qui operationem botri PostgreSQL administrare potest. Eodem tempore, ipso deficiente e cista non habet, ut opus tuum "involucrum" scribere debeas super solutionem paratam. Omnia igitur evenire possunt etiam magis implicata quam cum scriptis sui scriptis, quam ob rem nec temptavimus Repmgr.

AWS RDS

Sustentat omnia quae opus sunt, tergum facere potest ac lacus nexuum sustinet. Commutatio latae sententiae habet: cum dominus moritur, imago novus dominus fit, et AWS DNS testimonium novo domino mutat, dum replicationes in diversis AZs collocari possunt.

Incommoda denique occasus carentia complectitur. Exempli gratia subtilitatis: instantiae nostrae restrictiones habent pro nexus tcp, quae proh dolor in RDS fieri non possunt;

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

Praeterea AWS RDS duplo fere carus est quam pretium instantia regularis, quae causa principalis fuit solutionis huius deserendae.

Patroni

Hoc est exemplum pythonis administrandi PostgreSQL cum bonis documentis, deficientibus automaticis et source code in github.

Pros of Patroni:

• Quisque schematismi configurationis describitur, patet quomodo operatur;
• Automatic failover de archa operatur;
• In Pythone scripta, et quoniam ipsi in Pythone multa scribemus, facilior nobis erit quaestionibus agere et fortasse etiam rei evolutionem adiuvari;
• Plene moderatur PostgreSQL, permittit te statim mutare configurationem in omnibus nodis botri, et si applicando novam configurationem requirit sileo botri, id fieri potest denuo utendo Patroni.

cons:

• Non liquet ex documentis quomodo cum PgBouncer recte operari. Etsi difficile est hoc minus vocare, quia opus est Patroni PostgreSQL administrare, et quomodo necessitudines Patroni laborabunt, iam problema est nostrum;
• Pauca exempla patroni in magnis squamis exsequendi sunt, cum multa exempla de integro exsequantur.

Quam ob rem patroni deligimus ut racemum defectorem crearemus.

Patroni processum exsecutionem

Ante Patroni 12 shards PostgreSQL habuimus in uno domino et una figura figuralis cum replicatione asynchrona. Ministri applicationis accesserunt ad databases per Network Load Balancer, post quod duo instantiae apud PgBouncer erant, et post illos omnes servientes PostgreSQL fuerunt.


Ad efficiendum Patroni, botrum figurarum distributum deligi necesse erat. Patroni opera cum systematis systematis conformatione distributis ut etc., Zookeeper, Consul. Plenum curvum Consulem botrum in productione habemus, quod in conjunctione cum Vault operatur et amplius non utimur. Magna causa utendi consulis intendunt.

Patroni quomodo operatur cum Consule

Est botrus Consul, qui constat tribus nodis, et Patroni botri, qui constat a duce et effigie (in Patroni, dominus vocatur botrus dux, et servi replicationes). Instantia singula Patroni botri informationes de statu botri ad Consulem mittit. Unde ex Consule semper invenire potes hodiernam figuram Patroni botri et qui est princeps in tempore.

Patroni ad Consulem coniungere, iusta documenta officialia studeas, quae dicit te necesse esse exercitum in forma http vel https specificare, secundum quomodo cum Consule laboramus, et nexu schematis, optionally;

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

Simplex est, sed unde incipiunt foveae. Cum Consule per https nexum securum laboramus et nexum nostrum config sic videbimus:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Sed hoc modo non operatur. In startup, Patroni Consuli coniungere non possunt quia per http adhuc ire conatur.

Patroni codice fons adiuvit quaestionem solvendam. In Pythone hoc bonum est. Evenit ut parameter hospes nullo modo parsedtur, et protocollum in schemate specificetur. Hoc est quod figuratio laboratum clausus ad operandum cum Consule similis nobis est:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Consul-template

Sic nos elegimus schematismus conformationem. Nunc intelligendum est quomodo PgBouncer suam configurationem mutabit cum dux in Botrum Patroni mutat. Ad hanc quaestionem non est respondendum in documentis, quia... Principio operans PgBouncer ibi non describitur.

In solutione quaerens invenimus articulum (proh dolor, nominis non memini), ubi scriptum erat consul-templatum valde utile esse ad componendum PgBouncer et Patroni. Quae res nos ad studium consulendi.

Evenit ut Consul-templator constanter monitores configurationis PostgreSQL botri in Consule. Cum dux mutat, configurationem PgBouncer renovat et mandatum mittit ut eam reload.

Magna utilitas templates est quod reponitur in codice, ita cum novam contritionem addit, satis est novam committere ac renovare exemplar automatice, infrastructuram tamquam principium codicem sustinens.

Architectura nova cum Patroni

Quam ob rem hunc laboris ordinem recepimus;


Omnes applicationes servers ad libratorem accedunt → post eam duo sunt instantiae PgBouncer → in utroque instantia consul-templator currit, qui monitores status cuiusque Patroni botri et monitores ad momentum config PgBouncer, quae petitiones ad ducem currentem dirigit. cuiusque botri.

Manual probatio

Priusquam ad productionem illam deducimus, hoc schema in parva environment experimentum deiecimus et operationem mutandi automatico cohibuimus. Tabulam aperuerunt, obice et in ipso momento ducem botri "occidit". In AWS, omne quod debes facere, instantiam averte per consolatorium.

Obice intra 10-20 seconds rediit, et tunc iterum normaliter movere coepit. Hoc significat quod Botrus Patroni recte operati sunt: ​​ducem mutavit, nuntios ad Consulem misit, et Consul-templatum statim haec informationes sustulit, PgBouncer configurationem reposuit et mandatum reload misit.

Quam superesse sub alto onere et minimam downtime ponere?

Omnia perfecte operatur! Sed novae oriuntur quaestiones: Quomodo sub alto onere laborabit? Quam cito ac tuto evolvantur omnia in productione?

Experimentum environment in quo onere probationis agimus adiuvat nos respondere ad primam quaestionem. Omnino idem cum productione in architectura est ac testium notitiarum generavit, quae in volumine productioni proxime aequalis est. Statuimus iustos "occidere" unum ex dominis PostgreSQL in probatione et quid eveniat videre. Sed ante illud, refert, rollout automatic reprimendam, quia in hoc ambitu plures shards PostgreSQL habemus, ideo praeclaram probationem configurationis scriptorum ante productionem habebimus.

Ambitiosum utrunque spectant, sed nos PostgreSQL 9.6. Maybe possumus update ad 11.2 statim?

Statuimus hoc facere in tribus gradibus: primum renovatio versionis ad 2, deinde Patroni deducendae.

PostgreSQL renovatio

Ut celeriter versionem PostgreSQL renovare debes, optione utere debes -k, in quo ligatio dura in disco creata est et nihil opus est notitias tuas exscribere. In databases de 300-400 GB renovatio secunda 1 accipit.

Multum shards habemus, ideo renovatio automatice facienda est. Ad hoc faciendum nos playbook Ansible scripsimus, qui totum processum renovationis pro nobis exercet:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

Gravis est hic notare quod priusquam ab upgrade, illud cum modulo praestare debes --checkcerte upgrade fieri potest. Scriptum nostrum etiam supplet confis in upgrade. Scriptum nostrum 30 secundis perficitur, quod est optimum effectum.

Launch of Patroni

Ad secundam quaestionem solvendam, solum vide configurationem Patroni. Repositorium officiale exemplum habet configurationem cum initdb, quod respondere debet initialis nova datorum cum Patroni primum emissa est. Sed quoniam iam habemus database promptum factae, simpliciter hanc sectionem e figura removemus.

Cum Patroni instituere coepimus in parato facto PostgreSQL botrum et deducendo, novam quaestionem invenimus: ambo ministri in ducem deducti sunt. Patroni nihil scit de statu primo botri, et conatur currere ambos servientes quasi duas ligaturas in eodem nomine. Ad hanc solvendam quaestionem, indicem in servo delere debes:

rm -rf /var/lib/postgresql/

Hoc solum in servum fieri debet!

Cum figuram mundam coniungens, Patroni ducem base tergum facit et eam ad effigiem restaurat, et tunc cum statu currente ligna murorum utens prehendit.

Alia difficultas quae nobis occurrit, est quod omnes ligaturae PostgreSQL principales per defaltam vocantur. Cum uterque botrus de altero nihil scit, hoc normale est. Sed cum Patroni uti voles, omnes fasciculi singulare nomen habent. Solutio botri nomen mutandi in configuratione PostgreSQL.

Onus test

Experimentum intulimus quod simulat quomodo utentes in tabulis operantur. Cum onus ad nostrum quotidianum medium attigisset, eandem eandem probationem repetivimus, unam instantiam cum duce PostgreSQL devertimus. Automatis deficientis opera sicut expectavimus: Patroni ducem mutaverunt, Consul templatum configurationem PgBouncer renovaverunt et mandatum reload misit. Secundum graphes nostras in Grafana, apparebat moras 20-30 secundorum et parvam quantitatem errorum a ministris ad nexum datorum relatum. Haec condicio normalis est, huiusmodi valores nostro deficienti acceptabiles sunt et certe meliores sunt quam tempus operandi.

Lorem Patroni in productionem

Quam ob rem cum tali consilio venimus;

• Deploy consul-temptatum ad PgBouncer cultorem deducas;
• PostgreSQL updates to version 11.2;
• Mutato nomine botri;
• Emitte Patroni botrum.

Simul, propositum nobis permittit ut primum punctum fere quovis tempore agamus, unumquemque PgBouncer ab opere singillatim removere et instruere et in eo consuli speculari instruere. Id fecimus.

Ad vivos probationes, Ansible usi sumus, cum iam totum playbook in ambitu experimenti temptassemus, et tempus exsecutionis pro scriptura plena ab 1,5 ad 2 minuta pro singulis testae erat. Omnia singulatim ad singulas testas potuimus evolvi, sine nostro servitio intermissione, sed singulis minutis PostgreSQL declinare debebimus. In hoc casu, utentes, quorum notitia hac testa est, hoc tempore plene laborare non possunt, et hoc nobis ingratum est.

Via ex hac condicione conservanda est quae agimus singulis mensibus tribus. Haec fenestra est ad laborem accedendum, cum officium nostrum et instantiarum datorum renovationem omnino avertimus. Una septimana remansit usque ad proximam fenestram, et mox constituimus expectare et ulterius parare. Per insidias, etiam sponsiones nostras saepserunt: nam singulae PostgreSQL testae imaginem parcissimam in casu defectionis sustulimus, ut novissimas notitias servaremus, et novam instantiam pro singulis testae adiecimus, quae nova effigies in Patroni fieret. Botrus ne praeciperet delere data. Haec omnia adiuverunt ad minimize periculum erroris.


Servitium nostrum relegimus, omnia ut decet, utentes ad laborem perreximus, sed in graphis notavimus enormis altum sarcinam consulis servientibus.


Cur hoc in ambitu experimenti non videmus? Hoc problema valde bene illustrat oportere sequi principium Infrastructuram ut codicem et totam infrastructuram emendare, a gressibus ad productionem experimentis. Alioquin perfacile est problema quod obtinuit. Quid accidit? Consul primum in productione, deinde in ambitu testium apparuit, quam ob rem in ambitus versio consulis altior quam in productione fuit. Uno modo emissiones, CPU Leak cum opus consul-temptatum solutum est. Sic enim simpliciter Consul renovatus est, ita problema solvendum.

Sileo Patroni botrus

Nihilominus novam quaestionem nacti sumus quod ne suspicari quidem possumus. Cum adaequationis consulem simpliciter removemus nodi Consulem a botro utendo consul relinquas mandatum → Patroni connectit alteri consuli servo → omnia opera. Sed cum ad ultimum Consulis botrum instantia venissemus, et misissemus eum consuli mandatum, omnes Patroni ligaturas simpliciter restarted, et in lignis sequentem errorem vidimus;

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Botrus Patroni de botro suo cognoscere non potuit et restarted.

Ad solutionem inveniendam, Patroni per constitutionem in github auctoribus contingimus. Proponebant emendationes nostrae configurationis imagini:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

Replicare quaestionem in ambitu experimenti potuimus et has occasus ibi temptavit, sed proh dolor non laboravit.

Quaestio adhuc dubitatur. Sequenti solutiones cogitamus experior:

• Utere Consule agente in utroque instantia Patroni botri;
• Quaestionem in codice figere.

Subaudimus ubi error occurrit: forsit forsit est in usura defalta timeout, quae per limam configurationem non opprimitur. Cum ultimus Consul e botro sublato, totus Consul botrus constringitur, qui longior quam alter durat, ob hoc Patroni statum botri obtinere non possunt et totum botrum omnino sileo.

Feliciter, non amplius errores invenimus.

Eventus usus Patroni

Post felicis Patroni armationem in utroque botro additam addimus imaginem. Uterque autem botrus instar alicuius rei habet: unum ducem et duas replicationes, ad protegendum contra scindendum cerebrum cum mutando.


Patroni plus tribus mensibus in productione laboratum est. Per hoc tempus, iam nos adiuvat. Nuper dux unius uvarum in AWS mortuus est, deficientis automatis laboravit et utentes operari perseverunt. Patroni praecipuum munus suum perfecit.

Brevi summa usus Patroni:

• Otium de configurationis mutationibus. Satis est in unoquoque exemplo figuram mutare et totum botrum apponere. Si reboot requiritur ad novam configurationem applicandam, Patroni te de hac re certiorem faciam. Patroni sileo totum botrum cum uno praecepto, quod etiam est commodum.
• Automaton deficiente laborat et nos iam adiuvit.
• Adaequationis PostgreSQL sine applicatione downtime. Replicas ad novam versionem primum renovare debes, deinde ducem in Botrum Patroni mutare et ducem antiquum renovare. In hoc casu, necessaria probatio deficientis automatismi occurrit.

Source: www.habr.com