“Het is paradoxaal, maar waar, om te zeggen dat hoe meer we weten, hoe onwetender we worden in absolute zin, want alleen door verlichting worden we ons bewust van onze beperkingen. Precies een van de meest bevredigende resultaten van intellectuele evolutie is de voortdurende opening van nieuwe en grotere vooruitzichten.” Nikola Tesla
PostgreSQL is een geweldig project en het evolueert in een verbazingwekkend tempo. We zullen ons concentreren op de evolutie van fouttolerantiemogelijkheden in PostgreSQL in alle versies met een reeks blogposts.
PostgreSQL in een notendop
PostgreSQL is van nature fouttolerant. Ten eerste is het een geavanceerd open source databasebeheersysteem en viert het dit jaar zijn 20e verjaardag. Daarom is het een bewezen technologie en heeft het een actieve gemeenschap, waardoor het een snelle ontwikkelingsvooruitgang heeft.
PostgreSQL is SQL-compatibel (SQL:2011) en volledig ACID-compatibel (atomiciteit, consistentie, isolatie, duurzaamheid).
PostgreSQL maakt fysieke en logische replicatie mogelijk en heeft ingebouwde fysieke en logische replicatie-oplossingen. We zullen het hebben over replicatiemethoden (in de volgende blogposts) in PostgreSQL met betrekking tot fouttolerantie.
PostgreSQL maakt synchrone en asynchrone transacties, PITR (Point-in-time Recovery) en MVCC (Multiversion gelijktijdigheidscontrole) mogelijk. Al deze concepten zijn op een bepaald niveau gerelateerd aan fouttolerantie en ik zal proberen hun effecten uit te leggen terwijl ik de noodzakelijke termen en hun toepassingen in PostgreSQL uitleg.
PostgreSQL is robuust!
Alle acties op de database worden uitgevoerd binnen transacties , beschermd door een transactielogboek die automatisch crashherstel uitvoert in het geval van een softwarefout.
Databases kunnen optioneel worden gemaakt met datablokcontrolesommen helpen bij het diagnosticeren van hardwarefouten. Er bestaan meerdere back-upmechanismen, met volledige en gedetailleerde PITR, voor het geval er gedetailleerd herstel nodig is. Er is een verscheidenheid aan diagnostische hulpmiddelen beschikbaar.
Databasereplicatie wordt standaard ondersteund. Synchrone replicatie kan meer dan '5 Negens' (99,999 procent) opleveren beschikbaarheid en gegevensbescherming, indien correct geconfigureerd en beheerd.
Gezien de bovenstaande feiten kunnen we gemakkelijk beweren dat PostgreSQL robuust is!
PostgreSQL-fouttolerantie:WAL
Schrijf vooruit logging is het belangrijkste fouttolerantiesysteem voor PostgreSQL.
De WAL bestaat uit een reeks binaire bestanden die zijn geschreven naar de submap pg_xlog van de PostgreSQL-gegevensmap. Elke wijziging in de database wordt eerst vastgelegd in WAL, vandaar de naam "write-ahead" log, als synoniem van "transactielog". Wanneer een transactie wordt vastgelegd, is het standaard- en veilige gedrag om de WAL-records naar schijf te forceren.
Mocht PostgreSQL crashen, dan wordt de WAL opnieuw afgespeeld, waardoor de database terugkeert naar het punt van de laatste vastgelegde transactie, en zo de duurzaamheid van eventuele databasewijzigingen garandeert.
Transactie? Vastleggen?
Databasewijzigingen zelf worden niet naar schijf geschreven bij het vastleggen van een transactie. Die wijzigingen worden enige tijd later naar schijf geschreven door de achtergrondschrijver of checkpointer op een goed afgestemde server. (Controleer de WAL-beschrijving hierboven. )
Transacties zijn een fundamenteel concept van alle databasesystemen. Het essentiële punt van een transactie is dat het meerdere stappen bundelt in één alles-of-niets-operatie.
De tussenliggende toestanden tussen de stappen zijn niet zichtbaar voor andere gelijktijdige transacties, en als er een fout optreedt waardoor de transactie niet kan worden voltooid, heeft geen van de stappen invloed op de database. PostgreSQL ondersteunt geen dirty-reads (transactie leest gegevens die zijn geschreven door een gelijktijdige niet-vastgelegde transactie ).
Checkpoint
Crashherstel speelt de WAL opnieuw af, maar vanaf welk punt begint het te herstellen?
Herstel begint vanaf punten in de WAL die bekend staan als checkpoints . De duur van crashherstel hangt af van het aantal wijzigingen in het transactielogboek sinds het laatste controlepunt. Een controlepunt is een bekend veilig startpunt voor herstel, omdat het garandeert dat alle eerdere wijzigingen in de database al naar de schijf zijn geschreven.
Een controlepunt kan ofwel onmiddellijk . zijn of gepland . Onmiddellijke controlepunten worden geactiveerd door een actie van een superuser, zoals het CHECKPOINT commando of andere; geplande controlepunten worden automatisch bepaald door PostgreSQL.
Conclusie
In deze blogpost hebben we belangrijke features van PostgreSQL opgesomd die te maken hebben met fouttolerantie in PostgreSQL. We noemden write-ahead logging, transactie, commit, isolation levels, checkpoints en crash recovery. We gaan verder met PostgreSQL-replicatie in de volgende blogpost.
Referenties:
PostgreSQL-documentatie
PostgreSQL 9 Administration Cookbook – Tweede editie