User Tools

Site Tools


wiki:postgres:pg_tune_kurs_replication

Differences

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

Link to this comparison view

wiki:postgres:pg_tune_kurs_replication [2017/09/28 12:21] (current)
Line 1: Line 1:
 +====== Replikation ======
 +===== Traditionelles Transaction Log-Shipping =====
  
 +  * Archive
 +Vom Master aus werden x_logs in einem Pott archiviert (generische Archivierung). Der Pott kann dabei auf irgendeinem Server liegen (muß nicht Master oder Slave sein)
 +
 +  * restore-command
 +Der Slave holt sich die x_logs aus dem "​Pott"​ (mittels eines generischen restore-command).
 +\\
 +**Point in time recovery (PITR)**\\
 +
 +===== Streaming Replication =====
 +Streaming replication ermöglicht einem standby server mehr up-to-date zu sein als mit file-based log shipping möglich ist.\\
 +
 +==== 2 Kanäle ====
 +
 +  - **push**: der Master puscht - nach dem "fire and forget"​-Prinzip die x_logs so schnell wie möglich weg.
 +  - **Pull**: die Slaves ziehen die x_logs vom Master weg (sammeln auf).
 +
 +===== Basis Backup =====
 +  - Vom Master aus wird ein "base backup"​ gezogen.
 +  - **PITR:** Der Slave saugt zuerst aus dem "​Pott"​ (wie bei Transaction Log-Shipping);​ wenn er auf dem gleichen Stand ist schaltet er auf Streaming (Replication) um.
 +
 +===== Ausführung =====
 +==== Verzeichnisse (bzw. 2 möglichst idente Datenbanken) anlegen ====
 +
 +  postgres$ mkdir pot
 +  postgres$ mkdir slave
 +  postgres$ chmod 700 slave
 +
 +==== Archivieren der x_logs / die Strecke vom Master zum Pott einrichten ​ ====
 +
 +  postgresql.conf vom Master einrichten
 +  postgres$ vim .../​master/​.../​postgresql.conf
 +    listen_addresses = '​*' ​            #​besser nur die entsprechenden Server angeben - localhost vom Master und die IP-Adresse vom Slave.
 +    wal_level = hot_standby ​           #erzeugt mehr x_log'​s,​ da jetzt auch der Slave am Leben gehalten werden muss.
 +    archive_mode = on
 +    archive_command = 'cp %p /​home/​kurs/​pot/​ %f' ​  #hier ist z.B. rsync wesentlich besser. rsync ist atomic, d.h. die Datei wird
 +                                                   #​erstellt und anschließend umbenannt (wächst nicht langsam wie bei cp/rcp)
 +    max_wal_senders = 5   #5 Slaves dürfen sich streamend zum Master verbinden.
 +  ​
 +  postgres$ pg_ctl ... restart
 +
 +==== Einen Snapshot vom Master ziehen ====
 +  SELECT pg_start_backup('​some_name'​);​ --Snapshot ziehen - wartet auf einen Checkpoint.
 +  CHECKPOINT; ​                         --explizit einen Checkpoint setzen.
 +
 +==== Ein binär kompatibles Basis-Backup ziehen ====
 +Diese Kopie ist **per Definition inkonsistent**. d.h. Fehlermeldungen wie "file not found" etc. sind egal. Es wurde ja ein Checkpoint gesetzt -> Das Basisbackup kann inkonsistent sein, da es anschließend repariert werden kann (aus x_logs - wie auch sonst bei Transaktionen).
 +  postgres$ cp -Rv * /​tmp/​slave ​    #​binär kompatibles Backup vom "/data Verzeichnis";​ rsync o.ä. ist hier natürlich auch besser
 +
 +==== Dem Master bekanntgeben,​ dass das Basisbackup fertig ist ====
 +  SELECT pg_stop_backup('​some_name'​);​
 +
 +==== Slave-Konfiguration;​ die Strecken "​Pott-Slave"​ (restore-command) und "​Slave-Master"​ ====
 +=== postgresql.conf ===
 +
 +  postgres$ vi .../​slave/​.../​postgresql.conf
 +  ​
 +    hot_standby = on
 +    max_standby_archive_delay
 +    max_standby_streaming_delay = 30 s  #wie weit darf der Slave zurückliegen
 +    vacuum_defer_cleanup_age
 +
 +=== recovery.conf ===
 +
 +  postgres$ vi .../​slave/​.../​recovery.conf ​ #es gibt ein recovery.conf.sample als Grundlage in .../​share/​postgres
 +   
 +     ​restore_command = 'cp .../pot/%f %p' ​ #die Strecke Pott-Slave; besser rsync o.ä.
 +     ​standby_mode = '​on' ​                   #Streaming aktivieren
 +     ​primary_conninfo = '​host=localhost port = 5432' ​ #die Strecke Slave-Master
 +     
 +     # wann soll der Pot gelöscht werden
 +     ​archive_cleanup_command = '' ​   # wenn der Slave auf Streaming umstellt soll folgendes shell-skript aufgerufen werden.  ​
 +
 +     #​Point In Time Recovery (PITR)
 +     ​recovery_target_time
 +  ​
 +     #​Sobald das Trigger File existiert, weiß der Slave, daß er auf Streaming umstellen kann.
 +     ​trigger_file = ''​
 +
 +==== Permissions/​Berechtigungen für Slaves setzen ====
 +  postgres$ vi pg_hba.conf
 +    locale replication all             trust
 +    host   ​replication all 127.0.0.1/3 trust
 +    host   ​replication all ::​1/​128 ​    trust
 +
 +  postgres$ pg_ctl -D master reload ​   #​Konfiguration des Masters neu laden
 +  postgres$ pg_ctl -D slave  start     #​Slave starten
 +
 +===== Schlußbemerkungen =====
 +==== Binärkompatibilität ====
 +**Ein Slave der Master war kann nicht mehr Slave werden.** Transaction Log-Shipping ist eine Sache der Binärkompatibilität. Binär kompatibel //bedeutet aber nicht das die Prüfsumme//​ gleich ist, da auf dem Slave gewisse Hints nicht geschrieben werden die am Master geschrieben werden. Die Vervielfältigung von Slaves **funktioniert nicht mittels dump** sondern nur mit einem Filesystem snapshot (eben weil für Transaction Log-Shipping Binärkompatibilität gefordert ist).
 +==== Skytools ====
 +Kann auch **nur Teile der Datenbank** replizieren. Besser konzipiert als Slony (vergiss Slony - viel zu kompliziert - Masochismus).\\
 +Skytools sind Datenbank-Verwaltungs Programme von Skype: WAL shipping ( = Transaktion Log-Shipping ), Queueing und Replikation. **walmgr, PgQ und Londiste** [[http://​pgfoundry.org/​projects/​skytools/​|Skytools auf pgFoundry]].\\
 +Der Skytools "​walmgr"​ automatisiert den Vorgang den wir oben händisch gemacht haben.
wiki/postgres/pg_tune_kurs_replication.txt · Last modified: 2017/09/28 12:21 (external edit)