3. Replikacja systemu produkcyjnego

3.1. Założenia

  1. Uruchomione są dwie identyczne maszyny, na obu zainstalowane wszystkie serwisy (zakładam konfigurację all-in-one)

  2. Baza danych jest synchronizowana z produkcji na maszynę zapasową.

  3. W razie potrzeby, maszyna zapasowa dostaje adres publiczny i prywatny maszyny produkcyjnej, a baza danych przełączana jest w tryb produkcyjny.

    Warning

    Powrót nie jest łatwy, maszynka zapasowa stanie się nową produkcją, w miejsce starej produkcji można postawić dla niej serwer zapasowy.

3.2. Procedura

3.2.1. Synchronizacja bazy

Serwer zapasowy będzie na bieżąco pobierał informacje o zmianach na produkcji. Odbywa się to w oparciu o mechanizm WAL (Write Ahead Log)

3.2.1.1. Po stronie produkcji

  1. W pliku /etc/postgresql/9.1/main/postgresql.conf należy zmodyfikować:

    listen_addresses:
     (około linii 59) - serwer musi nasłuchiwać na interfejsie, na którym łączyła będzie się do niego maszyna zapasowa
    wal_level = hot_standby:
     (około linii 155) - dzięki temu do plików WAL zapisywane będzie wystarczająco dużo informacji, żeby odtworzyć bazę danych
    max_wal_senders = 1:
     (około lini 198) - ilość potoków, którymi będą wysyłane dane. Przy jednym serwerze zapasowym, powinno wystarczyć 1.
    wal_keep_segments = 64:
     (około linii 201) - ilość plików WAL, które będą przechowywane. Każdy z nich ma 16MB. Zajmują trochę miejsca, ale to potrzebne, żeby wszystko zdążyło się przesłać.
  2. Na końcu pliku /etc/postgresql/9.1/main/pg_hba.conf należy dodać linię:

    host     replication    postgres        adres_maszyny_zapasowej/32        trust
    
  3. Restart postgresa

service postgresql restart

3.2.1.2. Po stronie maszyny zapasowej

  1. Upewnić się, że użytkownik postgres ma rolę REPLICATION:

    ALTER ROLE postgres WITH REPLICATION;
    
  2. Zatrzymać bazę danych

    service postgresql stop
    
  3. Bez startowania bazy danych trzeba teraz wykonać kilka kroków na produkcji.

3.2.1.3. Po stronie produkcji

  1. Rozpoczęcie backupu bazy danych (jako postgres)

    SELECT pg_start_backup('mybackup_label', true);
    
  2. Skopiowanie bazy danych na serwer zapasowy

    scp -r /var/lib/postgresql/9.1/main/* serwer_zapasowy:/var/lib/postgresql/9.1/main/
    
  3. Zakończenie backupu bazy

    SELECT pg_stop_backup();
    

3.2.1.4. Wracamy na serwer zapasowy

  1. W pliku /etc/postgresql/9.1/main/postgresql.conf należy zmodyfikować:

    listen_addresses:
     (około linii 59) - powinien słuchać połączeń zprodukcji
    hot_standby = on:
     (około linii 210) - pozwala odczytywać bazę, ale zapis nie jest możliwy
  2. Skopiować plik /usr/share/postgresql/9.1/recovery.conf.sample do /var/lib/postgresql/9.1/main/recovery.conf i zmodyfikować:

    standby_mode = on:
     (około linii 108)
    primary_conninfo = ‘host=<adres_produkcji> port=5432 user=postgres’:
     (około linii 110) - dane połączenia do bazy produkcyjnej
    trigger_file = ‘/home/postgres/failover’:
     (około linii 124) - gdy ten plik się pojawi, serwer przejdzie ze slave do master - przestanie się synchronizować i zacznie umożliwiać zapis
  3. Kontrola uprawnień

chown -R postgres:postgres /var/lib/postgresql/9.1/main/
chmod 700 /var/lib/postgresql/9.1/main/
  1. Start bazy danych
service postgresql start
  1. Cieszymy się synchronizującą się bazą danych :)

3.2.2. Synchronizacja RRD (danych monitoringu)

Todo

Synchronizacja RRD

3.3. Przejście maszyny zapasowej w tryb produkcyjny

  1. Ustawienie adresów (publicznego i prywatnego) na maszynie zapasowej na takie, jak miała produkcja (teraz już nie może mieć ich ustawionych!)
  2. Utworzenie trigger_file
mkdir /home/postgres
touch /home/postgres/failover

Od teraz maszyna zapasowa przejęła rolę maszyny produkcyjnej. Po rozwiązaniu problemu ze starą maszyną produkcyjną, można wybrać któryś ze scenariuszy:

  • zostawić jak jest, w miejscu starej produkcji ustawić backup dla nowej produkcji
  • przenieść całą maszynę wirtualną tam, gdzie działała stara produkcja (wystąpi downtime!)
  • ustawić w miejscu starej produkcji maszynę zapasową dla nowej produkcji i wykonać procedurę failover