Hi omnes. Vladislav Rodin in tactu est. Hodie cursus doceo in Architectura Software Architectura et Architectura Architectura Archi-Stress Software apud OTUS. In antecessum novi cursum amnis Scribere decrevi brevem partem materiae originalis quam tecum communicare cupio.
introduction
Ex eo quod HDD solum circa 400-700 operationes per secundam praestare possunt (quae incomparabilis est cum rps typica ratio summi oneris), database orbis classici est bottleneck architecturae. Ideo oportet ut sedulo consideremus exemplaria huius tabulae elaboranda.
Currently, sunt 2 exemplaria scandendi database: replicatio et sharding. Sharing permittit ut operationem scribes scandere, et, consequenter, rps per scribe per servo tuo in botro minuere. Replicatio idem facere tibi permittit, sed cum operationibus legeris. Hoc est exemplar quod hic articulus vacat.
Replicatio
Si replicationem ad rem valde altam spectas, res simplex est: unum ministratorem habuisti, in eo data erat, et tunc hic servo diutius tolerare onere huius notitiae legendi non poterat. Additis duobus pluribus servientibus, data synchronise per omnes servientes, et usor ab aliquo servo in botro tuo legere potest.
Quamvis eius simplicitas appareat, multae sunt optiones ad varias exsecutiones huius schematis digerendas:
- Per munera in botro (domini vel domini servi)
- Per obiecti missi (row-fundatur, dicitur, aut secundum mixta)
- Secundum nodi synchronisation mechanismum
Hodie cum puncto 3 agemus.
Quomodo fit negotium commissum?
Hic locus non directe refertur ad replicationem, sed in eo scribendus est articulus separatus, sed quia ulterior lectio inutilis est sine intellectu negotii mechanismum committere, me admonere de rebus praecipuis. Transactio committere occurs in III gradus:
- Logging a transaction to the database log.
- Using a transaction in database engine.
- Rediens confirmatio ad clientem rem feliciter applicata est.
In diversis databases, hoc algorithmus nuances habere potest: exempli gratia, in InnoDB machinamento MySQL datorum 2 ligna sunt: unum ad replicandum (binarium logum), alterum ad conservandum ACID (undo/redo log), dum in PostgreSQL unus index est qui utrumque munera exercet (scribe praemisit log = WAL). Quod autem superius allatum est, notio omnino generalis est, quae talibus nuunciis non est habenda ratio.
Synchroni (sync) replicatio
Addamus logicam ad replicare receptas mutationes algorithmus transactionis:
- Logging a transaction to the database log.
- Using a transaction in database engine.
- Mittens data omnibus replicas.
- Confirmatio ab omnibus replicationibus peracta transactione super eis.
- Rediens confirmatio ad clientem rem feliciter applicata est.
Hac in re plura incommoda consequimur;
- hie observat mutationes applicandas omnibus replicationibus.
- sicut numerus nodis in botro augetur, nos minuimus verisimilitudo quod operatio scribentium prospera erit.
Si omnia cum primo puncto plus minusve clara sunt, rationes 1 puncti explicandae sunt. Si in replicatione synchrona responsum ab uno saltem nodo non accipimus, transactionem revolvimus. Sic, numerum nodis in botro augendo, verisimilitudinem auges quod operatio scribentis deficiet.
Exspectare possumus confirmationem e sola quadam recipis nodis, exempli gratia, ex 51% (quorum)? Possumus quidem, sed in versione classica, confirmatio ab omnibus nodis exigitur, quia hoc modo efficere possumus ut integrae notae constantiae in botro, quae sine dubio utilitas huius generis replicationis est.
Asynchronous (async) replicatio
Priorem algorithmum mitigemus. Notitias mittemus ad replicas "aliquando", et "quondam postea" mutationes applicabuntur ad replicas;
- Logging a transaction to the database log.
- Using a transaction in database engine.
- Rediens confirmatio ad clientem rem feliciter applicata est.
- Mittens notitias ad replicas et ad eas applicando mutationes.
Accessus ad hoc perducit quod botrus celeriter operatur, quia clientem exspectationem non servamus notitias ad replicandas et etiam committendas.
Conditio autem dumpingis notitiae replicas "aliquando" potest ducere ad amissionem transactionis, et ad amissionem transactionis confirmatae utentis, quia si data non vacat replicari, confirmatio clientis. de successu operationis emissae, et nodi, ad quem mutationes pervenerunt, ingruat HDD, rem amittimus, quae ingrata consequentia ducere potest.
replicatio semisync
Tandem ad replicationem semi-synchronam accedimus. Hoc genus replicationis non est notissimum vel valde usitatum, sed multum interest, quia commoda replicationis tam synchronae quam asynchronae coniungi potest.
Conemur 2 priora miscere aditus. Clientem non diu servabimus, sed notitia replicari postulabimus:
- Logging a transaction to the database log.
- Using a transaction in database engine.
- Mittens data ad replicas.
- Recepta confirmatione ex replica mutationes receptas (postmodum adhibebuntur).
- Rediens confirmatio ad clientem rem feliciter applicata est.
Quaeso note quod cum hoc algorithmo damnum transactionis nonnisi fit, si nodi et nodi accepti mutationes et replica nodi deficiunt. Probabilitas talis defectus humilis consideratur, et haec pericula admittuntur.
Sed cum hac accessu possibilis est periculum vatis legit. Fingamus sequentem missionem: in 4 gradu, confirmationem non habuimus ab aliqua effigie. Hanc transactionem revolvere debemus, nec confirmationem ad clientem referre. Cum notitia gradatim applicata 2, tempus intervallum est inter finem gradus 2 et regressionem transactionis, in quibus parallelae operationes videre possunt mutationes quae in datorum non debent esse.
Perdere-minus semisync replicationem
Si parum cogitas, gradus algorithm modo retexere potes et problema phantasmatis in hac missione legenti fige:
- Logging a transaction to the database log.
- Replica data mittens.
- Recepta confirmatione ex replica mutationes receptas (postmodum adhibebuntur).
- Using a transaction in database engine.
- Rediens confirmatio ad clientem rem feliciter applicata est.
Mutationes nunc committimus si replicatae fuerint.
conclusio,
Ut semper, nullae sunt optimae solutiones, certa est solutionum, quarum unaquaeque suas habet utilitates et incommoda et apta ad varias problematum classes solvendas. Hoc omnino verum est, mechanismum eligendo pro notitia synchroni in database replicata. Copia commoda quae replicatio semi-synchrona satis solida est et iucunda ut considerari possit attentione digna, non obstante eius praevalentia.
Id omne. Te videre !
Source: www.habr.com