User Tools

Site Tools


wiki:postgres:pg_tune_kurs_durable_von_acid

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

wiki:postgres:pg_tune_kurs_durable_von_acid [2017/09/28 12:21] (current)
Line 1: Line 1:
 +====== Das D(urable) in ACID ======
  
 +shared_buffers = Datenbank Cache.\\
 +Wenn der Strom ausfällt, wie stellt man sicher das die Daten konsistent bleiben (und z.b. nicht nur 2 Bits von 4 gesendeten Bits in ein Tabellenfeld geschrieben werden). Dies impliziert, daß ein UPDATE nicht überschreiben darf und daß direkt in die Tabelle schreiben auch nicht funktioniert.
 +
 +===== write ahead log (WAL) =====
 +[[http://​www.postgresql.org/​docs/​9.0/​static/​continuous-archiving.html|Continuous Archiving and Point-In-Time Recovery (PITR)]]\\
 +WAL prokokolliert mit (Prüfsumme oder was immer) - in sequentielles Band eingefügt - und wenn die Daten nicht vollständig sind sieht man das dann.\\
 +\\
 +**pg_xlog** records: hier stehen alle binären Änderungen (d.h. frei von Semantik) drinnen.
 +**WAL:** Zuerst wird das pg_xlog geschrieben und dann erst die Daten - write ahead log wird vor den Daten geschrieben.\\
 +Wnn der x_log unvollständig ist, dann passiert kein COMMIT und der konsistente Zustand der Tabelle kann aus dem Transaktions-Log ( = x_log = WAL ) wieder hergestellt werden.\\
 +\\
 +Eine Änderung wird durchgeführt:​ Zuerst in Cache ( = shared_buffers ) geschrieben,​ dann als "​dirty"​ markiert **(dirty buffer)**. Aber vorerst noch nicht in die Tabelle geschrieben. (d.h. die Tabelle ist immer hinten nach -> die Tabelle ist nicht konsistent!).\\
 +Eine Datei schreiben heißt: es wird zunächst vom "User space" in den "​Kernel space" geschrieben und dann erst irgendwann auf die Festplatte/​Disk (Grund dafür: Speed).\\
 +
 +==== FSYNC und F_Fullsync = Disk flush ====
 +  [postgres@ibm ~]$ man fsync
 +... "​transfers ("​flushes"​) all modified **in-core data** of (i.e., modified buffer cache pages for) the file referred to by the file descriptor __fd__ to the disk device (or other permanent storage device) where the file resides. ...\\
 +\\
 +Der Kernel schreibt "out of order",​ d.h. er fasst die Bits und Bytes so zusammen, daß es am effektivsten ist. Die Festplatte wiederum bestimmt anders zu schreiben, weil sie dadurch z.b. einen kürzeren Weg hat. Und zu guter Letzt können sich RAID-Controller etc. auch noch in das Ganze einschalten und buffern.\\
 +Dadurch können sich Einträge auch **überholen**. z.B. kann ein DELETE des selben Datensatzes ankommen bevor die Daten überhaupt mit INSERT angekommen sind!\\
 +Daher gibt es noch **F_Fullsync**,​ welches die exakte "​Order"​ etc. gewährleistet.\\
 +\\
 +==== Check point ====
 +Nun ist sichergestellt dass die Daten im Transaktions-log sind. Das Transaktionslog kann abgeschnitten werden **( = Check Point )**, sobald sichergestellt ist, daß die Daten physisch in die Tabelle geschrieben sind. (Es ist auch notwendig das x_log abzuschneiden,​ da es ja nicht unendlich lang werden kann).\\
 +Wurde das x_log am Check point abgeschnitten so wird der dirty buffer in den shared_buffers gelöscht.\\
 +**Die Daten müssen in der Tabelle stehen __und__ die Tabelle muß __"​geflusht"​__ (physisch auf Disk geschrieben) werden.**\\
 +\\
 +**Das x_log wird nur im Crash-Fall gelesen, sonst nie.**\\
 +
 +\\**x_log = transaction log = write ahead log(WAL)**\\
 +\\
 +
 +===== Cashing Algorithmus =====
 +**2Q-Clocksweep**\\
 +2Q's - Wenn ein Block verwendet wird kommt er wieder in die erste Q (1Q).\\
 +Wenn sich ein Block bereits in der zweiten Q (2Q) befindet und längere Zeit (Clock, deshalb Clocksweep) auf diesen Block nicht zugegriffen wird fällt er aus dem Cache raus und wird geschrieben.\\
 +x_log muß daher immer der Tabelle voraus sein, sonst kann nicht repariert werden.
wiki/postgres/pg_tune_kurs_durable_von_acid.txt · Last modified: 2017/09/28 12:21 (external edit)