Cheque Dejeuner

Popis prostředí

Hostingove prostredi rozprostrene pres 1 cluster (*.seky.sit.cldn.eu) na sitelu a replikovana cast bezi na Lh3 take na sitelu. Zatim je na kazde strane postgres, nginx a windows server. Kazde cast prostredi ma separatni vlanu na kazdem hostu (clu + lh3). Na fw1(2) se mezi vlanama routuje.

Z vpn se uzivatel dostane po celem prostredi.

V hostingovem prostredi jsou i stroje, ktere nemaji zadnou funkci v aplikaci GB (GalleryBeta), ty jsou instalovany na popud Cheque Dejeuner a vetsinou to jsou separatni web servery atp.

OpenVPN

Po pripojeni do VPNky dostanete routy takove, abyste se dostali vsude
kam Vas pusti firewall vazany na jednotl. uzivatelske jmena. To se bude
nastavovat dle dohody kdo ma kam mit pristup.

VPNka pouziva spolecny certifikat pro vsechny ucty + se zadava username
a heslo.

Prilozen soubor s konfiguraci OVPN klienta.

Strucny popis aplikace

Na IIS bezi webova aplikace a aplikacni server. Webova aplikace se stara pouze o zobrazeni, ale veskerou logiku obsluhuje aplikacni server, se kterym web komunikuje pres JSON. URL projektu je http://shop.gallerybeta.cz
Mezi CDJCZ a hostingovym prostredim je navazan IPSEC tunel pouzivany pro vymenu dat mezi hostingovym prostredim a IBM AS/400 v sekach. Vymena probiha pres mysql db ktera bezi na hostingu. Aplikace do ni zapisuje data a z centraly CDJCZ si je stahuji do AS400

Na hostingu je redundance nastavena takto:
DNS zaznam ukazuje na jeden z proxy serveru (clu). Tento proxy server checkuje dostupnost aplikace na obou windows serverech pomoci upstream_checku a definovane URL. Jeden (clu) aplikacni server je jako hlavni, druhy je nastaven jako backup, prebira praci kdyz prvni nebezi. Aplikacni servery si zase testuji dostupnost postgres db. DB bezi v replikaci master/slave a aplikace udajne umi pro RO operace pouzit blizsi db (clu-clu, lh3-lh3), i kdyz je v slave modu, takze RO provoz se rozklada mezi oba PGSQL. RW operace bezi pochopitelne pouze proti masteru.

Kontakty

Aplikaci gallerybeta programuje spol. Mokasoft, konkretne p. Hanel. Co se tyce gallerybeta, ma tuto posloupnost kontaktu:

Seznam strojů:

Podrobnější info k winserverům

viz KlientDejeuner

Zalohovani

Vetsina VM se zalohuji na backup5.zab.cldn.eu. Specialni zalohovani se pouziva u obou db. Jednak se db zalohuji bezne, az na db data. Data se zalohuji v separatnim hostu koncicim na "_dbonly" .

Na primarni db (sitel) se kazdou noc dela base backup (konzistentni souborova zaloha), ktera je umistena do " /var/lib/pgsql/9.2/backups/daily-bak/hostname-date". Dale backuppc pri spusteni zalohy spusti skript "/usr/local/scripts/rotate-wal.sh", ktery rekne db, aby switchnula do noveho WAL logu (redo log), takze tesne pred zalohou mame v "/var/lib/pgsql/9.2/backups/wal" posledni mozny WAL soubor. K obnoveni db potrebujeme libovolny base backup a vsecky WAL od jeho vytvoreni, tzn. idealne base backup z noci a nasledujici WAL. Zaloha se pousti 4x denne, kdy vlastne dozalohuje pribyvsi WAL soubory.

Na standby strane (casablanca) se zalohuje pomoci pg_dumpu. Pred kazdou zalohou backuppc spusti "/usr/local/scripts/pgbak_dump.sh", ktery udela do "/var/lib/pgsql/9.2/backups/daily-bak" konzistentni dump. Zalohuju tak zejmena proto, pokud budou vyvojari potrebovat nejakou cast db, aby se nemuselo rozebihat cele postgres prostredi a obnovovat z base backupu.

Dalsi vec, ktera se nezalohuje uplne standartne je virtual "mysql". Pouziva se jak MyISAM, tak InnoDB, takze se zalohuje jednou tydne plna zaloha a 6x inkrementalni pomoci percona xtrabackup: http://www.percona.com/doc/percona-xtrabackup/2.1/
Obnovu lze provest pomoci navodu: full, incremental

Pokud se tedy zmeni role db (master/slave), je potreba zalohy upravit.

Predavani zaloh:
Cas od casu maji seky nebo mokasoft pozadavek na zalohu db ze vcerejska atp, v tom pripade stahnu jednu z sql zaloh postgresu (postgres.casa, na sitelu se dela base backup - souborovej) dle jejich casoveho urceni a tuto zalohu jim zasifrovanou zpristupnim. Typicky rozbalim tar, ktery je produktem backuppc, protoze uvnitr je gzipnuty dump. Tento dump nasledne zasifruju prikazem:

openssl enc -in <filename.sql> -aes-256-cbc -e > <filename encrypted>

Je dobre silne heslo, protoze to bude vystavene venku. Nasledne to vystavim na ftp store.bosson.eu, coz je v linux/STORE a pres jabber/email-gpg poslu heslo k souboru a pripojim mu command na desifrovani

openssl enc -in <filename encrypted> -aes-256-cbc -d > <filename.sql>

Hesla a pristupy:

Vzdaleny pristup

servery pro gallerybeta
Z domecku je mozne se pripojit na VPN stroj

ssh root@109.205.75.35 -p10002

VPN stroj:

ldap na sitel_vpn (ovz_dejeuner.sitel_vpn:8080):

ldap na casa+vpn (ovz_dejeuner.casa_vpn:8080)

heslo do aplikace shop.gallerybeta.cz:

useri na linux VM:

DB useri na gb_postgres (192.168.26.102)

useri na win VM:

user do samby(192.168.26.107): - gb_samba

user do mysql (192.168.26.106) - gb_mysql

user do mysql (192.168.26.116) - gb_web

CRM

useri do mysql(192.168.53.108 - crm.seky.cz a crmslave)

ostatni

useri do mysql(192.168.26.110 - ovz_seky_weby)

phpMyAdmin bezi na pma.seky.cz, povoleno z par IP vc. domecku

DNS related:

hesla z papiru ktery nevim kam patri:

Co delat v pripade vypadku

Pamatuj! Vsechny operace s postgresem delat jako user postgres, aby se predeslo problemum s pravy (su - postgres)

Vypadek slave casti reseni - LH3

Protoze aktualne pouzivame asynchronni repliku, pri vypadku slave reseni neni treba nic delat.

Vypadek slave casti reseni - stare (LH3)

synchronous_standby_names = ''

service postgresql-9.2 restart

Vypadek primaru (clu)

Jednak je treba prepnout postgres slave do master modu. Musime si byt jisty, ze puvodni master neobzivne, tzn. musime to zajistit treba na urovni clusteru nebo VM.

clusvcadm -d lvguest:gb_postgres
chkconfig postgresql-9.2 off

Pokud sme si jisti (spadnul node/cluster kde master bezel), prepneme slave na master tim, ze vytvorime trigger file. V konfiguraci /var/lib/pgsql/9.2/data/recovery conf je trigger nastaven na:

trigger_file = '/tmp/postgresql.master.trigger'

Takze staci udelat:

touch /tmp/postgresql.master.trigger

a tim se prepne postgres do master rezimu, viz log. Cesta zpet je popsana nize. Aktualni stav master/slave se zjisti query:

postgres=# SELECT pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 f
(1 row)

Navratova hodnota false (f) znamena ze pgsql je master, true (t) znamena slave.

Druha vec je prepnuti DNS na LH3. Za predpokladu ze nebezi sitel, tak na dns v casablance (service:ovz_dejeuner.casa_dns) zmenime zony gallerybeta.cz a my-up-gallery.eu:

vim /var/lib/knot/gallerybeta.cz
vim /var/lib/knot/my-up-gallery.eu

Nahradni zaznamy jsou tam zakomentovany, takze staci odkomentovat a znovupodepsat zonu a reloadnout knot, coz udela skript:

/usr/local/scripts/resign-zones-casa.sh

To je si vse.

DNS system

Kvuli mozne zmene DNS pri vypadku lokality budou relevantni domeny u nas. Protoze jsou zabezpeceny DNSSECem, bude to malicko slozitejsi. Zaroven nechci delat Master-Slave? konfiguraci DNS, protoze pokud vypadne lokalita, kde pobezi master, tezko se bude rekonfigurovat narychlo slave na master. Na sitelu je (nyni) posledni bind, na casablance knot na debianu a data se synchronizuji rsyncem.

Zmena v zone

Primarne menime zony na sitelu!
Pokud chceme zmenit zonu, postupujeme nasledovne:

1) cd /var/named/masters/
2) vim gallerybeta.cz
3) zmenim zaznamy + zmenim serial
4) spustime skript /usr/local/scripts/resign-transfer-zones.sh – ten znovupodepise vsechny zony, reloadne binda a prenese zmenene zony do casy, kde reloadne knot

Pokud vypadne sitel, tak zonu menime primo na case. Opet editujeme bezne zonu a pote ji znovupodepiseme skriptem, ktery i reloadne knot

1) cd /var/lib/knot
2) vim gallerybeta.cz
3) /usr/local/scripts/resign-zones-casa.sh

Kdyz se sitel navrati, musime na nej zmeny prenest, a nebo na sitelu zvetsit serial nad serial casy a spustit "resign-transfer-zones.sh"

Pridani zony na nameservery gallerybeta a podepsani DNSSECem

1) kroky nize provadime v adresari zon, u nas: /var/named/masters
2) Vytvorime beznou textovou zonu pro danou domenu pojmenovanou po domene (/var/named/example.com)
3) vygenerujeme ZSK (zone sign key):

dnssec-keygen -3 <jmeno domeny>

a KSK (key sign key):

dnssec-keygen -3 -fk <jmeno domeny>

4) zonu podepiseme prave vytvorenou sadou klicu:

dnssec-signzone -S <jmeno domeny>

5) do nameserveru pridane konfiguraci zony s tim, ze pouzijeme podepsanou zonu, tzn. <zona>.signed:

zone "cafeteriasystem.cz" {
        type master;
        file "/var/named/masters/cafeteriasystem.cz.signed";
};

6) do korenove zony (napr. .cz zony) musime vlozit info o nasem KSK klici. Informaci o KSK klici se rika DS zaznam. DS zaznam do korene vlozime bud tak, ze registratorovi predame rovnou DS zaznam (napr. pro eu domenu) a nebo pouzijeme celou verejnou cast KSK klice a vytvorime napr. keyset zaznam (.cz domena). Keyset je obdoba NSSETu, jen obsahuje public cast KSK. Nas ukazkovy keyset: http://www.nic.cz/whois/?k=ks-gb-2 (u nas se podepisuje kazda zona svym KSK klicem, takze kazda zona ma jiny KEYSET)

DS zaznam je ulozen v souboru ddset-<zona>, ktery se vytvori pri generovani klicu. V ddset souboru jsou typicky 2 DS zaznamy, lisi se pouzitym typem hashovaci funkce. Typicky se pouziva prvni, kratsi DS zaznam. Ten zadame do administrace registratora nebo posleme klientovi at udela totez. DS zaznam se da zjistit i utilitou:

dnssec-dsfromkey -1 <KSK key file>

7) Upravime skript /usr/local/scripts/resign-transfer-zones.sh, tak aby podepisoval i novou zonu (promenna ZONES) a spustime ho. Skript znovupodepise vsecky zony a prenese je na "sekundar", tj. casablancu. Tam upravime obdobnej skript a zaroven pridame zonu do Knot DNS (opet .signed soubor) a reloadneme knota.
8) Po vsech upravach muzeme zonu zkontrolovat napr. na : http://dnssec-debugger.verisignlabs.com/

9) DS zaznam pro zonu je ulozen v korenove zone dane narodni zony, takze ji zjistime dotazem na nejaky NS narodni domeny:

dig ds gallerybeta.cz @c.ns.nic.cz

;; ANSWER SECTION:
gallerybeta.cz.         18000   IN      DS      50058 7 1 3B6ECF417431F8FAE100F655AB4BA314C55AD7F9

Zmena SSL certifikatu

Kvuli bazirovani na bezpecnosti ze strany zakazniku CDJ jsem nastavil DANE (TLSA) zaznam pro shop.gallerybeta.cz. TLSA zaznam obsahuje (v nasem pripade) otisk SSL certifikatu pouziteho pro https://shop.gallerybeta.cz, takze nelze zmenit (MiTM) SSL certifikat bez toho aniz by se to dalo zjistit (a TLSA je chranene DNSSECem). V pripade nutnosti zmeny se da zaznam bud pregenerovat nebo vyhodit ze zony. Generuje se (na strane sitelu) takto:

tlsa --create --protocol tcp --port 443 --usage 1 --selector 1 --mtype 1 shop.gallerybeta.cz

Prace s postgresem

Drobnosti

vypis configuracnich promennych:

postgres=# show all;

zjisteni, zda-li je zapnuta synchronni replika: (pokud je standby_names nastaveno na vse (*) a commit na "on", pak se pouziva synchronni replika

postgres=# show synchronous_standby_names;
 synchronous_standby_names 
---------------------------
 *
(1 row)

postgres=# show synchronous_commit;
 synchronous_commit 
--------------------
 on
(1 row)

Zjisteni pripojenych replik a jejich mod (sync):

postgres=# select client_addr, state , sync_state from pg_stat_replication;
  client_addr   |   state   | sync_state 
----------------+-----------+------------
 192.168.53.102 | streaming | sync
(1 row)

Vypsani locku:

SELECT * FROM pg_locks WHERE NOT granted;

Vypsani running queries:

SELECT datname,pid,client_addr,query FROM pg_stat_activity;

Aktualni stav master/slave se zjisti query:

postgres=# SELECT pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 f
(1 row)

If it's true, you're on a slave; if false, master.

get current value of setting:

current_setting(setting_name)

set parameter and return new value:

set_config(setting_name, new_value, is_local)

Cancel a backend's current query

pg_cancel_backend(pid int)

Zjisteni posledniho autovacuumingu a analyze pro danou db:

-bash-4.1$ psql gallerybeta_production
gallerybeta_production=# select relname, last_autovacuum, last_autoanalyze from "pg_catalog"."pg_stat_all_tables";

Zmena ownera db/schematu

Na sitelu ve /var/lib/pgsql je skript change_ownership.sh. Nastavuje se systemovyma promennyma, napr:

export PGHOST=localhost PGUSER=postgres PGDATABASE=gallerybeta_production PGPORT=5432 PGPASSWORD=xxxx

pak spustime skript a jako parametr -n uvedeme noveho ownera db a -S je schema ktere chceme menit (defaultne public):

sh change_ownership.sh -n gb_production -S public

Lepsi je se tomuto vyvarovat a uploadovat dump/vytvaret db pod jiz danym chtenym ownerem

Zalozeni usera

-bash-4.1$ psql
psql (9.2.4)

postgres=# create role uvttest;
CREATE ROLE

postgres=# ALTER ROLE uvttest ENCRYPTED PASSWORD 'testuvtDB';
ALTER ROLE

postgres=# ALTER ROLE uvttest LOGIN; 
ALTER ROLE

postgres=# ALTER ROLE uvttest CREATEDB; 
ALTER ROLE

echo "local   all             uvttest                                 md5" >> /var/lib/pgsql/9.2/data/pg_hba.conf
echo "host    all             uvttest         127.0.0.1/32            md5" >> /var/lib/pgsql/9.2/data/pg_hba.conf

service postgresql-9.2 reload

Vytvoreni db

DB vytvarime tak, aby ji vlastnil zamysleny owner, protoze zmena ownera neni trivialni. Owner ma pak vsechny prava nad db. V prikladu pouzijeme jako ownera nahore vytvoreneho "uvttest"

Take zalezi jakou pouzijeme templatu, protoze pokud vytvarime db pro obnovu sql dumpu, pak je potreba pouzit template0, protoze:

When restoring, always use template0 explicit, as it is always an empty and unmodifiable database. If you don't use an explicit template, PostgreSQL will assume template1, and if it has some objects, like a table or function that your dumped database already has, you will get some errors while restoring.

[root@ovz_dejeuner.casa_postgres ~]# su - postgres
-bash-4.1$ createdb -U restore -T template0 db_restore_cz

Postgres vytvari db defaultne v systemovem encodingu. Aby se s tim lepe pracovalo, je lepe si na serveru nastavit encoding na UTF8:

[postgres@develpostgres.gallerybeta.cz ~]$ cat /etc/sysconfig/i18n 
LANG=en_US.UTF-8

To udelat pred prvotni inicializaci db (service postgres initdb), protoze pak se defaultne vytvari v UTF8 vse.

Obnova db ze zalohy (binarni zaloha celeho postgresu)

Na backuppc (viz sekce Zalohy) se zalohujou denni base zalohy (base.tar.gz v adresari s casovym razitkem) a WAL soubory (Write-Ahead Logging). Potrebujeme nejnovejsi zalohu a od ni vsechny WAL dale az do konce. Stahneme tedy prislusny soubor base.tar.gz a archiv (klidne vsech) WAL souboru s nazvem napr. wal_restore.gtar a ulozime je do adresare /tmp na serveru s databazi. Na serveru je dobre mit nejlepe stejne prostredi, tj. stejny OS a verzi PGSQL, nejlepe i stejne uid uzivatele postgres.

Prvne se ujistime, ze databaze skutecne nebezi. Prihlasime se jako uzivatel postgres (toto je dulezite, viz sekce Co delat v pripade vypadku), smazeme cely obsah adresare data, je-li nejaky, a rozbalime tam base zalohu a z ni smazeme/presuneme WAL segmenty (mame-li ze zalohy cerstve)

-bash-4.1$ su - postgres
-bash-4.1$ cd
-bash-4.1$ pwd
/var/lib/pgsql
-bash-4.1$ cd 9.2/data/
-bash-4.1$ tar -xzf /tmp/base.tar.gz
-bash-4.1$ cd pg_xlog/  #zde mazeme WAL soubory obsazene v base.tar.gz
-bash-4.1$ rm ./*

Dale zkopirujeme WAL segmenty do adresare, kam se na produkci archivuji (zde 9.2/data/backups/wal) - (pripadne se co 5 minut rsyncuji take na slave do /var/lib/pgsql/9.2/backups/wal-from-master) , a nastavime recovery.conf v datovem adresari pgsql na tento archiv:

-bash-4.1$ pwd
/var/lib/pgsql/9.2/data
-bash-4.1$ cd backups
-bash-4.1$ mkdir wal # pokud neexistuje
-bash-4.1$ cd wal
-bash-4.1$ tar -xf /tmp/wal_restore.gtar
-bash-4.1$ cd ../.. # zpet do adresare data
-bash-4.1$ cat postgresql.conf  | grep "archive_command"
archive_command = 'cp -i %p /var/lib/pgsql/9.2/backups/wal/%f' # tento cp prikaz musime zapsat do restore.conf, ale s opacnymi parametry
-bash-4.1$ echo "restore_command = 'cp /var/lib/pgsql/9.2/backups/wal/%f "%p"'" >> /var/lib/pgsql/9.2/data/recovery.conf

A nastartujeme DB:

-bash-4.1$ servise postgresql-9.2 start
-bash-4.1$ tail -f /var/log/messages

Nov 21 09:53:37 dan postgres[5722]: [1-1] LOG:  database system was interrupted; last known up at 2013-11-21 01:01:01 GMT
Nov 21 09:53:37 dan postgres[5722]: [2-1] LOG:  creating missing WAL directory "pg_xlog/archive_status"
Nov 21 09:53:37 dan postgres[5722]: [3-1] LOG:  starting archive recovery
Nov 21 09:53:37 dan postgres[5722]: [4-1] LOG:  restored log file "0000000600000000000000B3" from archive
Nov 21 09:53:37 dan postgres[5722]: [5-1] LOG:  redo starts at 0/B3000020
Nov 21 09:53:37 dan postgres[5722]: [6-1] LOG:  consistent recovery state reached at 0/B30000E0
Nov 21 09:53:37 dan postgres[5719]: [1-1] LOG:  database system is ready to accept read only connections
Nov 21 09:53:37 dan postgres[5722]: [7-1] LOG:  restored log file "0000000600000000000000B4" from archive
Nov 21 09:53:37 dan postgres[5722]: [8-1] LOG:  restored log file "0000000600000000000000B5" from archive
Nov 21 09:53:37 dan postgres[5722]: [9-1] LOG:  restored log file "0000000600000000000000B6" from archive
Nov 21 09:53:37 dan postgres[5722]: [10-1] LOG:  restored log file "0000000600000000000000B7" from archive
Nov 21 09:53:37 dan postgres[5722]: [11-1] LOG:  could not open file "pg_xlog/0000000600000000000000B8" (log file 0, segment 184): No such file or directory
Nov 21 09:53:37 dan postgres[5722]: [12-1] LOG:  redo done at 0/B7000758
Nov 21 09:53:37 dan postgres[5722]: [13-1] LOG:  last completed transaction was at log time 2013-11-21 13:30:12.564673+00
Nov 21 09:53:37 dan postgres[5722]: [14-1] LOG:  restored log file "0000000600000000000000B7" from archive
Nov 21 09:53:37 dan postgres[5722]: [15-1] LOG:  selected new timeline ID: 7
Nov 21 09:53:37 dan postgres[5722]: [16-1] LOG:  archive recovery complete
Nov 21 09:53:38 dan postgres[5719]: [2-1] LOG:  database system is ready to accept connections
Nov 21 09:53:38 dan postgres[5737]: [2-1] LOG:  autovacuum launcher started

-bash-4.1$ psql uvttest
psql (9.2.5)
Type "help" for help.

uvttest=# 
uvttest=# \d
           List of relations
 Schema |    Name    | Type  |  Owner  
--------+------------+-------+---------
 public | testobnovy | table | uvttest
(1 row)

uvttest=# select * from public.testobnovy;
 radek1 | radek2 
--------+--------
      1 |      1
      2 |      2
      3 |      3
      4 |      4
(4 rows)

Zabezpeceni DB - odebrani default privileges:

postgres=# REVOKE ALL ON DATABASE gallerybeta_production FROM PUBLIC;
REVOKE
postgres=# REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE
postgres=#

Zaloha a obnova pres pg_dump a pg_restore

Obnovovat pomoci pg_restore lze pokud je pg_dump udelat "postgres" stylem, cili nikoliv sql dump. Ten se obnovuje pres psql utilitu.

Zaloha:

pg_dump -Fc gallerybeta_production -f 9.2/backups/gb_dump_30.11.2015

Obnova, pricemz chceme pouzit jineho ownera db, nez je v dumpu (a zaroven restornout pouze schema public, jinak to hazi chyby)

pg_restore --no-owner --role=pg_devel_sk -n public -d pg_devel_sk 9.4/backups/gb_dump_30.11.2015

Musi nam souhlasit encoding db, viz kapitola vytvareni db:

postgres=# \l
                                    List of databases
    Name     |    Owner    | Encoding |   Collate   |    Ctype    |   Access privileges   
-------------+-------------+----------+-------------+-------------+-----------------------
 pg_devel_sk | pg_devel_sk | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 postgres    | postgres    | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 template0   | postgres    | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
             |             |          |             |             | postgres=CTc/postgres
 template1   | postgres    | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
             |             |          |             |             | postgres=CTc/postgres

Obnova ze SQL dumpu

Nejdrive vytvorime usera, viz vyse, dale vytvorime db, viz vyse (pouzijeme template0) a nasledne obnovime:

psql -U restore db_restore_cz -f 9.4/backups/gallerybeta_production-2016-01-18-08_00_08.sql

Znovuobnoveni replikace

Toto delame napr. po padu masteru, kdy prepneme bezici slave do master rezimu a po znovunahozeni byv. masteru na nem potrebujeme znovu nahodit repliku (byt obracene, puvodni master bude slave)

VSE DELAME JAKO USER POSTGRES, aby sme si nerozbili nekde prava

master server:

su - postgres
-bash-4.1$ mkdir /var/lib/pgsql/9.2/backups/onetimebak
-bash-4.1$ /usr/pgsql-9.2/bin/pg_basebackup -D /var/lib/pgsql/9.2/backups/onetimebak/ -F tar -z -Z 4 -x -U postgres

slave server:
1) schovat si postgresql.conf, pg_hba.conf a recovery.conf
2) smazat obsah adresare data
3) do adresare data rozbalit base backup ziskany na masteru, viz postup na master serveru
4) vratime nase konfigy
5) pokud jsme slave predtim protnuli na master, smazeme pripadny trigger_file, aby promote neprobehl znovu a prejmenujeme recovery.done na recovery.conf
6) spustime server

Jan  7 10:22:13 postgres2 postgres[2015]: [1-1] LOG:  database system was interrupted; last known up at 2014-01-07 09:49:00 EST
Jan  7 10:22:13 postgres2 postgres[2015]: [2-1] LOG:  creating missing WAL directory "pg_xlog/archive_status"
Jan  7 10:22:13 postgres2 postgres[2015]: [3-1] LOG:  entering standby mode
Jan  7 10:22:13 postgres2 postgres[2015]: [4-1] LOG:  redo starts at 0/33000020
Jan  7 10:22:13 postgres2 postgres[2015]: [5-1] LOG:  consistent recovery state reached at 0/330000E0
Jan  7 10:22:13 postgres2 postgres[2012]: [1-1] LOG:  database system is ready to accept read only connections
Jan  7 10:22:13 postgres2 postgres[2019]: [2-1] LOG:  streaming replication successfully connected to primary

Optimalizace vykonu postgresu

Zmenou techto parametru zacal postgres fungovat rychleji, alespon pro potreby GB. Pravdepodobne vyrazne pomohla zmena random_page_cost, ktera je defaultne nastavena na 4, coz je pomerne dost na moderni RAID, takze planner si mysli ze ma disky pomalejsi nez skutecne jsou a snazi se vice eliminovat nahodny pristup na data.

Feb 10 15:08:37 ovz_dejeuner postgres[446]: [8-1] LOG:  parameter "work_mem" changed to "32MB"  - sort a jine zpracovani pouzivaji tuto pamet
Feb 10 15:08:37 ovz_dejeuner postgres[446]: [9-1] LOG:  parameter "checkpoint_segments" changed to "8" - max. pocet WAL segmentu mezi checkpointy (nebo checkpoint_timeout) dle toho co prijde driv.) Znamena to ze vetsi bulk insert se muze vejit do WAL segmentu a teprve potom je v klidu checkpointnut do db. Take to ale znamena delsi recovery v pripade crashe (je dobre mit rozumny checkpoint_timeout)
Feb 10 15:08:37 ovz_dejeuner postgres[446]: [10-1] LOG:  parameter "checkpoint_timeout" changed to "10min" - checkpoint delat bud pri zaplneni WAL a nebo po <timeoutu>, viz vyse
Feb 10 15:08:37 ovz_dejeuner postgres[446]: [11-1] LOG:  parameter "random_page_cost" changed to "2.0" - hint pro planner jak drahe jsou random IO -> default = 4, dobry RAID ~ 2.5, SSD RAID ~ 2
Feb 10 15:08:37 ovz_dejeuner postgres[446]: [12-1] LOG:  parameter "effective_cache_size" changed to "4096MB" - kolik ramky zbyva po nastartovani PG na page cache - hint pro planner, nic nealokuje
Feb 10 22:06:57 ovz_dejeuner postgres[446]: [14-1] LOG:  parameter "effective_io_concurrency" changed to "4" - zhruba pocet disku v raidu (bez paritnich u R5/6)
Feb 10 22:06:57 ovz_dejeuner postgres[446]: [15-1] LOG:  parameter "checkpoint_completion_target" changed to "0.9" - v jakem case mezi checkpointama dokoncit predchozi. Cim delsi obdobi mezi CP (0-1), tim plynulejsi IO zatez
Feb 11 09:41:08 ovz_dejeuner postgres[649]: [9-1] LOG:  parameter "log_min_messages" changed to "notice" - logujeme vice
Feb 11 09:41:08 ovz_dejeuner postgres[649]: [10-1] LOG:  parameter "log_checkpoints" changed to "on" - ddto
Feb 11 09:56:06 ovz_dejeuner postgres[446]: [20-1] LOG:  parameter "log_autovacuum_min_duration" changed to "0" - logujeme veskere autovacuum operace

IPSEC

Na hostingu je KVM stroj kvm-dejeuner.sitel-ipsec, ktery zprostredkovava ipsec do centraly seku kvuli prenosu nejakych informaci z mysql serveru (192.168.26.106). IPSEC je nastaven pouze na prenos dat mezi mysql (u nas) a 10.10.32.9 + 10.10.32.201 u seku.

Dalsi IPSEC spojeni je sestaveno do centraly Groupe Chéque Déjeuner ve Francii (spojeni gcdfr). Opet spojuje mysql a AS400. Protoze nase sit je v presahu se siti ve Francii, poslali nam IP adresu 10.249.3.1/32, na kterou se ma provoz z 192.168.26.106 NATovat. Protoze ale v linuxu nelze SNATovat pred odchodem paketu do IPSECu (postroutingem odchazi paket uz zasifrovany), udelal jsem to jednoduse tak, ze danou IP jsem nahodil na mysql serveru a provoz na ni je z ipsec koncentratoru naroutovan po LAN 192.168.26.106 na mysql server

Na IPSEC serveru je firewall, ktery povoli pouze specifikovane sluzby.

Antispam

Antispam bezi na postfixu/amavisu, prijima vsechno a preposila to na jejich exchange. Spamy a viry se jim neposilaji, ale konci v quarantene, odkud se maily starsi 3 mesice mazou cronem.

pridani domeny na antispam

1) /etc/postfix/main.cf -> pridame domenu do "virtual_mailbox_domains"
2) /etc/postfix/antispam -> priradime domene FILTER (tj. antispam) a spustime "postmap /etc/postfix/antispam
3) /etc/postfix/transport -> priradime domene transport. Pro seky mame staticky zaznam v hosts, protoze maji 2 konektivity, takze pokud nefunguje jedna, snazi se dorucit na druhou. K tomu je jeste potrebne nastaveni resolveru v main.cf. Spustime postmap /etc/postfix/transport

vypnuti TLS pro domenu

Pokud nelze odeslat postu na nejakou domenu kvuli problemum s TLS, lze pro tuto domenu TLS vypnout zapisem do /etc/postfix/tls_policy, napr.: ppgtrading.cz none a nasledne spustit postmap /etc/postfix/tls_policy

SMTP a mailing pro GB

Pro gallerybeta existuji 2 mailservery podle ucelu pouziti:

odesilani obchodnich mailu z aplikace GB smerem ke klientum nebo sekum:

Na serveru gb_vpn bezi nekolik instanci postfixu: main, de a sk. Jsou to instance pro jednotlive instance gallerybeta a slouzi jako odesilac posty, s tim, ze chyby odeslani mailu, zpozdeni atp chodi rediteli pro vyvoj do seku.

mailing server:

Slouzi k odesilani reklamnich mailu nejen pro GB, ale i pro seky atp. Je oddelen od "provozniho" smtp, zejmena aby nechodili chyby v dorucovani Albrechtovi a druhak, aby ho nezahltili a pak nebyla zpozdovana regulerni posta z GB

DKIM

Na mailingu se odchozi posta podepisuje DKIMem, asi bude vhodny, az bude cas, udelat podepisovani i na provoznim smtp