Magis clientes sequentes petitiones accipiunt: "Volumus eam sicut Amazon RDS, sed vilius"; "Volumus eam sicut RDS, sed ubique, in qualibet infrastructura." Ad solutionem tam expeditam in Kubernetes deducendam, inspeximus praesentem statum operariorum popularium PostgreSQL (Stolon, operariorum e Crunchy Data et Zalando) et electionem nostram fecimus.
Hic articulus est experientia, quam consecuti sumus tum ex parte speculativa (solutionum solutionum) et ex parte practica (electus et quid inde). Sed primum videamus quaenam requisita generalia sint in potentia substituendi pro RDS...
Quod RDS
Cum homines de RDS loquuntur, in nostra experientia, significant ministerium quod administratum DBMS:
- facile configurare;
- habet facultatem opus cum snapshots et ab eis recuperet (potissimum cum auxilio );
- permittit tibi topologias magistros creandi;
- extensionum uberem habet;
- praebet auditing et usor / accessum procuratio.
Communiter accedit ad exsequendum munus quod prope potest esse longe alia, sed via cum Ansible conditionali non appropinquat nobis. Collegae ex 2GIS ad similem conclusionem creare "instrumentum celeriter explicandi Postgres-fundatur failover botrum portassent.")
Communis aditus est operariorum ad similia problemata solvenda in oecosystematis Kubernetes. Directorium technicum "Flanta" fusius de illis iam locutus est in relatione ad databases intra Kubernetes deductas. apud .
NB: Ut cito efficiant simplices operatores, commendamus attentionem ad utilitatem nostram Sources Open . Utens, hoc facere potes sine scientia Go, sed modis magis familiaribus ad administratores systematis: in Bash, Python, etc.
Plures sunt operarii populares K8s pro PostgreSQL:
- Stolon;
- Crunchy Data PostgreSQL Operator;
- Zalando Postgres Operator.
Eos propius inspiciamus.
Operator lectio
Praeter notas praecipuas iam supra memoravimus, nos - sicut Kubernetes fabrorum operationes infrastructuras - etiam sequentes ab operariis exspectavimus;
- deployment ex Git et cum ;
- pod anti- affinitatis auxilio;
- nodi affinitatis vel nodi selectoris insertis;
- tolerantiae institutionem;
- promptitudinis capabilities ;
- technologiae intelligibiles ac etiam mandata.
Praeter singula in singulis punctis (quaeris in commentationibus, si adhuc habeas de illis quaestiones post totum articulum perlectis), generaliter notabo has parametris necessarias esse ad specializationem nodis racemorum accuratius describendam. iubeas eas pro certis applicationibus. Hoc modo consequi possumus stateram meliorem in terminis faciendis et sumptus.
Nunc ad ipsos operatores PostgreSQL proficiscamur.
1. Stolon
ex comitatu Italico Sorint.lab in velut signum quoddam apud operatores pro DBMS habebatur. Hoc consilium satis vetus est: prima publica missio reversa mense Novembri 2015(!), et repositio GitHub gloriatur fere 3000 stellarum et 40+ contributorum.
Stolon quidem egregium est architecturae curiosae exemplum;
Fabrica huius operantis singillatim in relatione inveniri potest vel . In universum satis est dicere posse omnia quae descripti sunt: ββdefectores, procuratores ad accessum perspicuum clientis, tergum... Porro proxies accessum per unum finem muneris praebent - dissimiles aliae duae solutiones infra delatae (singula duo operas habent pro basi accessu).
Sed Stolon quam ob rem ita explicari non potest ut facile et velox est - "sicut placentae calidae" - ad instantias DBMS in Kubernetes creare. Procuratio exercetur per utilitatem stolonctlinstruere fit per chart Helm et consuetudines in Mando definitis et definitis.
Ex altera parte, evenit ut operans revera non sit operator (cum CRD non utitur). Sed contra, ratio flexibilis est quae te permittit ut facultates K8s configurare, ut tibi visum est.
Summatim, nobis personaliter non bene visum est chartulam separatam pro singulis datorum creare. Ergo utrumque quaerere coepimus.
2. Crunchy Data PostgreSQL Operator
, iuvenis Americanus satus, quasi altercatio logica videbatur. Eius historia publica a prima emissione mense Martio 2017 incipit, quia tunc promptarium GitHub sub 1300 astris et 50+ contributoribus accepit. Novissima emissio a Septembri temptata est cum Kubernetis 1.15-1.18 laborare, OpenShift 3.11+ et 4.4+, GKE et VMware Inceptum PKS 1.3+.
Architectura Crunchy Data PostgreSQL Operator etiam postulata praedicta occurrit:
Procuratio fit per utilitatem pgotamen consuetudines Resources pro Kubernetes generat. Placuit ergo nobis auctor utentes in potentia;
- imperium per CRD est;
- administratio usoris opportuna (etiam via CRD);
- integrationem cum aliis components β collectio specialissima continens imagines pro PostgreSQL et utilitates ad operandum cum ea (including pgBackRest, pgAudit, extensiones a contrib, etc.).
Nihilominus inire nititur utens operante de Crunchy Data nonnullas difficultates revelavit:
- Nulla possibilitas tolerandi - solum nodeSelector provisus est.
- Siliquae creatae partem instruere erant, non obstante quod applicationem publicam laxaverunt. Dissimilis StatefulSets, instruere discos creare non potest.
Incommodum novissimum ducit ad momenta ridicula: in ambitu experimenti nos currimus 3 replicas cum uno orbe locus reponofaciens operator nuntiare 3 replicas laborabant (etsi non erant).
Aliud notum huius operantis est eius praeparata integratio cum variis systematibus auxiliaribus. Exempli gratia, facile est pgAdmin et pgBounce installare, et in pre- figuratus Grafana et Prometheus habentur. In recentibus Integratio melioris consilii separatim notatur e quibus auctor claram visualizationem PgSQL metricam e archa offert.
Sed alienae facultates Kubernetes-generatae selectae nos ad necessitatem perduxerunt ut diversam solutionem inveniret.
3. Zalando Postgres Operator
Zalando producta diu cognovimus: Zalenium usus experimur et, utique, conati sumus est popularis HA solutio pro PostgreSQL. De societatis accessu ad partum unus ex auctoribus suis Alexey Klyukin dixit in aere ac nobis placuisse.
Haec est minima solutio in articulo discussa: prima missio mense Augusto MMXVIII facta est. Attamen, licet paucitas formalium emissiones, consilium longe obvenit, iam popularis solutionem a Crunchy Data cum 2018+ stellis in GitHub et maximum numerum contributorum (1300+).
"Sub cucullo" hic operator solutiones temporariae utitur:
- Patroni and Ad inpellendum;
- β ad tergum;
- β nexum lacus.
Haec est architectura quam operator ab Zalando praesentatur;
Auctor per Custom Resources plene administratur, automatice rem publicam e vasis creans, quae tunc fieri potest nativus variis sideribus ad vasculum additis. Haec omnia notabile commodum prae operante Crunchy Data est.
Cum solutionem a Zalando inter optiones 3 propositas elegerimus, ulterior descriptio facultatum eius infra exhibebitur, statim cum praxi applicationis.
Exercere cum Postgres Operator ex Zalando
Operans instruere valde simplex est: modo depone hodiernam emissionem GitHub et applica fasciculos YAML e indicem . Vel, etiam uti potes .
Post institutionem, solliciti sitis de instauratione . Hoc fit per ConfigMap postgres-operator in spatio nominali quo operator inauguratus es. Repositoria olim configurata, primum PostgreSQL botrum pandere potes.
Exempli gratia: vexillum nostrum instruere hoc vult:
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
name: staging-db
spec:
numberOfInstances: 3
patroni:
synchronous_mode: true
postgresql:
version: "12"
resources:
limits:
cpu: 100m
memory: 1Gi
requests:
cpu: 100m
memory: 1Gi
sidecars:
- env:
- name: DATA_SOURCE_URI
value: 127.0.0.1:5432
- name: DATA_SOURCE_PASS
valueFrom:
secretKeyRef:
key: password
name: postgres.staging-db.credentials
- name: DATA_SOURCE_USER
value: postgres
image: wrouesnel/postgres_exporter
name: prometheus-exporter
resources:
limits:
cpu: 500m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
teamId: staging
volume:
size: 2Gi
Haec manifesta explicat botrum 3 instantiarum cum sidecar in forma e qua applicatione metrica sumimus. Ut videre potes, omnia valde simplicia sunt, et si vis, potes indefinitum numerum uvarum proprie creare.
Valet attendentes interretialem administrationem tabula - . Is cum operante venit et dat uvas creare et delere, sicut operari cum tergum factis ab operante.
Index uvarum PostgreSQL
Tergum procuratio
Alius interesting pluma est firmamentum . Hoc mechanism automatice creates muneribus in PostgreSQL, fundatur in indice usorum indefinitorum. API tunc te permittit referre indicem usorum pro quibus functiones automatice creatae sunt.
Problemata et solutiones
Attamen usus operantis mox plures defectus significantes revelavit;
- defectus nodeSelector auxilio;
- non posse inactivandi tergum;
- cum functione creationis datorum utens, defalta privilegia non apparent;
- Interdum documenta desunt vel extra diem.
Feliciter multa eorum solvi possunt. Sit a fine incipere - problems with documentum.
Verisimile est, quod non semper perspicies quomodo tergum subcriptio et quomodo tergum situla coniungendi operanti UI. Documenta de hoc obiter loquitur, sed vera descriptio inest :
- clam facere opus est;
- consequenter operante modulo
pod_environment_secret_namein CRD cum operatoribus fundis vel in ConfigMap (prout quomodo volueris auctor instituere).
Sed, sicut evenit, hoc nunc est impossibile. Ideo collegimus cum nonnullis additis tertiae partis explicationibus. Plura de eo vide infra.
Si parametri transeas ad tergum operantis, nempe - wal_s3_bucket et accessum claves in AWS S3, tunc erit tergum omnianon solum bases, sed etiam choragium. Hoc nobis non convenit.
In parametri descriptione pro Spilo, quod est principale involucrum Docker pro PgSQL cum operante utens, evenit: modulum transire potes. WAL_S3_BUCKET vacua, ita inactivare tergum. Magnum praeterea gaudium inveni quas statim in furcam nostram recepimus. Iam vos iustus postulo addere enableWALArchiving: false ad PostgreSQL botrum portassent resource.
Ita opportunitas fuit aliter currendo 2 operatores ferendi: una ad currendum (sine tergum), altera ad productionem. Sed una facere potuimus.
Bene, discimus aditum ad databases transferre pro S3 et tergum in tabularium inire coeperunt. Quomodo paginae tergum ut operantis UI laborant?
Necesse est ut Operator UI 3 variabiles addere:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Postea, procuratio tergum in promptu erit, quae in casu nostro opus choragii simpliciorem reddet, sino nos ut illic pecias a productione sine scriptoribus adiectis liberare sinamus.
Alia utilitas fuit opus cum Teams API et ampla occasiones creandi databases et munerum utentium instrumentorum operatorium. Sed creatum partes non habebant iura per defaltam. Itaque utentis cum iuribus legitimis novas tabulas legere non potuit.
Cur est? Non obstante quod in codice necesse est GRANTnon semper adhibita. Sunt 2 modi: syncPreparedDatabases ΠΈ syncDatabases. Quod syncPreparedDatabases - non obstante quod in sectione preparedDatabases est conditio defaultRoles ΠΈ defaultUsers ad partes creandas, iura defalta non applicantur. In processu sumus commissuram praeparandi ut haec iura automatice applicantur.
Ultimum autem punctum in emendationibus quae ad nos pertinent -. quae addit Node Affinitatem creato StatefulSet. Clientes nostri saepe malunt impensas reducere adhibitis locis instantiis, et non sunt operae database obnoxiae perspicue dignae. Hic exitus per tolerationes resolvi potuit, sed praesentia Nodis Affinitas maiorem fiduciam praebet.
Quid accidit?
Ex eventibus solvendis quaestionibus supradictis bifurcam Postgres Operatoris Zalando into ubi colligitur tam utiliter inaequaliter. Et ad maiorem utilitatem nos etiam collegimus .
Index PRs in furcam acceptus:
- ;
- ;
- ;
- .
Grande erit si communitas hos PRs sustineat ita ut cum altera operantis versione fluant (1.6).
Bonus! Productio transitus victoria fabula
Si Patroni uteris, productio viva migrare potest ad operator minimo temporis momento.
Spilo sino vos creare sto clusters per S3 repono cum cum PgSQL stipes binarius primum in S3 reponitur, deinde per imaginem exantlaretur. Sed quid facerem, si habes? non usus est in Wal-E vetus infrastructure? Solutio huius quaestionis iam est in centrum.
PostgreSQL replicatio logica succurrit. Sed non singillatim pergamus quomodo publicationes et subscriptiones creandi, quia consilium nostrum fiasco fuit.
Ita res est, quod plures tabulas oneratas datorum miliones ordinum habuere, quae praeterea assidue repletae erant et deletae sunt. Ρ copy_dataCum nova effigies imitetur omnia contenta magistri, simpliciter apud dominum tenere non potest. Contentus describendi per hebdomadam laboravi, sed numquam cum magistro captus est. In fine, me adiuvit problema solvere collegae ab Avito: notitia utens transferre potes pg_dump. versionem nostram algorithmi describemus.
Idea est quod subscriptionem debilem facere potes ad certam replicationem socors ligatam, et numerum transactionis corrige. Replicae ad opus productionis praesto fuerunt. Hoc magni momenti est quod effigies adiuvabit constantem TUBER creare et mutationes a domino accipere perseveret.
Mandata sequentia processus migrationis describentes utendi sequentes notationes exercitus erunt:
- dominus β fons servo;
- replica1 β effusis effigies veteris productionis;
- replica2 β Replica logicae novae.
Donec adipiscing consilium
1. Subscriptionem magistri pro omnibus tabulis in schemate crea public basis dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Replicatio socors crea in magistrum:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Desine replicationem veteris imaginis;
psql -h replica1 -c "select pg_wal_replay_pause();"
4. numerus a domino posside transactionem:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. TUBER veterem imaginem remove. Hoc in pluribus sequelis faciemus, quae processum accelerare iuvabunt;
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. upload TUBER ad novum server:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Post demptionem TUBER, replicare potes in figura fluenti:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. Subscriptionem in novam imaginem logice faciamus:
psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"
8. demus oid subscriptiones:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. Dicamus receptum oid=1000. Applicare rem numero in subscriptione:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. Replicatio committitur:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Perscriptio status subscriptionis, replicatio operari debet;
psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"
12. Post replicationem incepit et databases synchronisedantur, transire potes.
13. Post inactivare replicationem, sequentia corrigere debes. Hoc bene descriptus est .
Hoc consilio switchover minimis moras factum est.
conclusio,
operarii Kubernetes permittunt te ad varias actiones simpliciores reducendo eas ad facultates K8s creandas. Tamen, cum earum ope praeclara automation consecuta, memoria dignum est quod plures etiam inopinatis nuances efficere potest, ut operatores tuos prudenter elige.
Consideratis tribus operariis maxime popularibus Kubernetes pro PostgreSQL, consilium ab Zalando elegimus. Et aliquas difficultates cum ea vincere debebamus, sed eventus vere gratum fuit, ut hanc experientiam aliis PgSQL officinarum amplificare instituimus. Si experientiam similem solutionis habes, singula in commentaria videre gaudebimus!
PS
Lege etiam in nostro diario:
- Β«";
- Β«";
- Β«".
Source: www.habr.com