Replikation PostgreSQL slawischen multi

Aus De Ikoula wiki
Jump to navigation Jump to search

de:Replikation PostgreSQL slawischen multi en:Replication PostgreSQL Slavic multi he:שכפול מרובה PostgreSQL סלאבית ro:Replicare PostgreSQL slave multi ru:Multi PostgreSQL славянских репликации pl:Replikacja wielu słowiańskich PostgreSQL ja:レプリケーション PostgreSQL スラブ マルチ ar:النسخ المتماثل السلافية كيو متعدد zh:复制 PostgreSQL 斯拉夫语多 nl:Replicatie PostgreSQL Slavische multi it:Replica PostgreSQL slavo multi pt:Replicação PostgreSQL eslavo multi es:Replicación multi de PostgreSQL Slavic fr:Replication PostgreSQL multi slaves

Dieser Artikel wurde maschinell übersetzt. Sie können den Artikel Quelle hier ansehen.

Einführung

Diese Seite beschäftigt sich mit der Umsetzung einer asynchronen PostgreSQL Streaming-Replikation mit einem Master und zwei Slaves. Unsere slawischen wird als hot-Standby konfiguriert werden, das heißt, dass es möglich ist zu laufen Abfragen (nur lesen ) auf diesen.


Zusammenhang mit dieser Platzierung :


Wir haben 3 Debian-Server 8 (zuletzt aktualisiert: ) :

Postgres 01 (10.1.1.75) : werden unser Meister

Postgres02 (10.1.1.90) : wird ein Sklave

Postgres03 (10.1.1.199) : wird ein zweite Slave


Angegebenen Befehle als Root ausführen, wenn sie vorangestellt werden "#" und als Postgres-System-Benutzer Wenn sie vorangestellt "$".

Installation von PostgreSQL und Vorkonfiguration der drei Server

Alle Befehle in diesem Teil sind auf jedem Server erfolgen.

Als ersten Schritt, es empfiehlt sich, eine Datei /etc/hosts mit die Spiele der einzelnen Server wie folgt aufgefüllt (durch die Anpassung mit den Hostnamen und IP-Adressen von Ihren eigenen Servern ) : 

# cat /etc/hosts
127.0.0.1       localhost

10.1.1.75       Postgres 01
10.1.1.90       Postgres 02
10.1.1.199      Postgres 03


Fügen Sie die Kaution APT PostgreSQL : 

# echo "deb http://apt.postgresql.org/pub/repos/apt/ jessie-pgdg main" > /etc/apt/sources.list.d/postgres.list


Wir importieren Sie den öffentlichen Schlüssel dieser Lagerstätte : 

# gpg --keyserver pgpkeys.mit.edu --recv-key 7FCC7D46ACCC4CF8 && gpg -a --export 7FCC7D46ACCC4CF8 | apt-key add -
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: requesting key ACCC4CF8 from hkp server pgpkeys.mit.edu
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key ACCC4CF8: public key "PostgreSQL Debian Repository" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK


Es aktualisiert den Cache APT die Kaution berücksichtigen : 

# apt-get update


Installation von Paket Postgresql (installieren Sie die neueste stabile Version ist der 9.5 zum Zeitpunkt, wo diese Zeilen geschrieben sind ) : 

# apt-get install postgresql


Wir definieren ein Kennwort (seiner Wahl aber sicher ) und erzeugt ein ssh-Schlüsselpaar (ohne Passphrase ) für den Systembenutzer Postgres : 

# passwd postgres

# su - postgres

$ ssh-keygen


Wir kopieren die Benutzer Postgres von und zwischen jedem öffentlichen Server ssh Schlüssel :


Seit dem ersten Server (postgres01 in unserem Fall ) in Richtung der zweiten (postgres02 für uns ) und Troisiseme (postgres03) : 

root@postgres01:~# su - postgres

postgres@postgres01:~$ ssh-copy-id postgres02

postgres@postgres01:~$ ssh-copy-id postgres03


Vom zweiten auf den ersten und dritten Server : 

root@postgres02:~# su - postgres

postgres@postgres02:~$ ssh-copy-id postgres01

postgres@postgres02:~$ ssh-copy-id postgres03


Vom dritten auf den ersten und zweiten Server : 

root@postgres03:~# su - postgres

postgres@postgres03:~$ ssh-copy-id postgres01

postgres@postgres03:~$ ssh-copy-id postgres02

Die Masterkonfiguration

Nur auf dem Master tun (postgres01 in unserem Fall ) :


Es legt die Rolle /Replikation Benutzer : 

# su - postgres

$ psql -c "CREATE USER repuser REPLICATION LOGIN CONNECTION LIMIT 2 ENCRYPTED PASSWORD '<mot de passe repuser>';"

Hinweis : Es definiert eine Verbindungsbeschränkung 2 denn wir haben 2 Slawische


Die wichtigsten Postgresql-Konfigurationsdatei bearbeiten /etc/postgresql/9.5/main/postgresql.conf die folgenden Richtlinien konfigurieren : 

listen_addresses = '*'
wal_level = hot_standby
archive_mode = on
archive_command = 'rsync -av %p postgres@<ip du premier slave>:/var/lib/postgresql/wal_archive/%f'
max_wal_senders = 2
wal_keep_segments = 256
hot_standby = on

Hinweis : Wir ermöglichen Archivierung zu unserem zweiten Server (Passen Sie Ihre IP-Adresse des Servers ) für noch mehr Vorsichtsmaßnahmen. Wir definieren auch die Parameter Hot_standby, Brunnen, der auf einem Master ignoriert wo sollte es in Zukunft Slave degradiert werden.


Jetzt bearbeiten Postgresql Authentifizierungsdatei /etc/postgresql/9.5/main/pg_hba.conf Unsere Replikation Benutzer berechtigt sind, eine Verbindung von unserer slawischen oder die folgende Zeile am Ende der Datei hinzufügen : 

hostssl replication     repuser <ip du réseau de vos serveurs>/24     md5

Bitte passen Sie diese Zeile nach dem Namen des Benutzers Replikation und Netzwerk (oder entsprechenden IP-Adressen ) der Ihre slawischen


Neustart den Postgresql-Service um unsere Konfiguration berücksichtigen (in Wurzel ) : 

# systemctl restart postgresql


Dadurch wird sichergestellt, dass der Dienst ordnungsgemäß gestartet wird : 

root@postgres01:~# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
   Active: active (exited) since Thu 2016-06-02 12:06:28 CEST; 22s ago
  Process: 77056 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 77056 (code=exited, status=0/SUCCESS)



root@postgres01:~# ps -u postgres u
USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
postgres  77038  0.0  4.4 227300 21836 ?        S    12:06   0:00 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.
postgres  77040  0.0  0.8 227300  4160 ?        Ss   12:06   0:00 postgres: checkpointer process
postgres  77041  0.0  1.0 227300  4968 ?        Ss   12:06   0:00 postgres: writer process
postgres  77042  0.0  1.7 227300  8776 ?        Ss   12:06   0:00 postgres: wal writer process
postgres  77043  0.0  1.3 227728  6708 ?        Ss   12:06   0:00 postgres: autovacuum launcher process
postgres  77044  0.0  0.6  82244  3392 ?        Ss   12:06   0:00 postgres: archiver process
postgres  77045  0.0  0.8  82244  4244 ?        Ss   12:06   0:00 postgres: stats collector process

Konfiguration der Slawen

Auf dem ersten Slave

Wir beginnen mit der Haltestelle den Postgresql-Service : 

# systemctl stop postgresql


Die wichtigsten Postgresql-Konfigurationsdatei bearbeiten /etc/postgresql/9.5/main/postgresql.conf die gleichen Richtlinien als Master konfigurieren, durch maßgeschneiderte nur die Ip des ersten Sklaven vom zweiten Sklaven in den Befehl Rsync, entweder zu archivieren : 

listen_addresses = '*'
wal_level = hot_standby
archive_mode = on
archive_command = 'rsync -av %p postgres@<ip du second slave>:/var/lib/postgresql/wal_archive/%f'
max_wal_senders = 2
wal_keep_segments = 256
hot_standby = on


Jetzt bearbeiten Postgresql Authentifizierungsdatei /etc/postgresql/9.5/main/pg_hba.conf Unsere Replikation Benutzer berechtigt sind, von unseren anderen Servern verbinden hinzufügen (Dies wird verwendet, wenn dieser Sklave erwartet Meister gefördert ) : 

hostssl replication     repuser <ip du réseau de vos serveurs>/24     md5

Hinweis : Mit dieser Konfiguration ähnlich wie unser Meister wird damit um dieser Sklave als Master im Bedarfsfall leicht zu fördern.


Für die folgenden Vorgänge, melden Sie sich als Benutzer des Systems Postgres : 

# su – postgres


Wir erstellen das Zielverzeichnis für die Wal der master Archive : 

$ mkdir /var/lib/postgresql/wal_archive


Es entfernt das Postgresql Datenverzeichnis : 

$ rm -rf /var/lib/postgresql/9.5/main


Es macht die Basissicherung (passen Sie die Ip deines Meisters und den Namen des Benutzers Replikation ), das Kennwort für Ihre Replikation Benutzer werden Sie aufgefordert : 

$ pg_basebackup -h <ip de votre master> -D /var/lib/postgresql/9.5/main -U repuser -v -P --xlog


Es konfiguriert die Replikation durch Anlegen der Datei /var/lib/postgresql/9.5/main/recovery.conf mit den folgenden Parametern : 

standby_mode = on
primary_conninfo = 'host=<ip de votre master> port=5432 user=repuser password=<mot de passe de repuser> sslmode=require application_name=<hostname de votre slave>'
trigger_file = '/var/lib/postgresql/9.5/postgres.trigger'

Hinweis : Die Trigger-Datei ist die Datei, die wir erstellen, wenn wir wollen, dass seine slave-Replikation stoppt und startet Einträge zu akzeptieren – wenn man es als Master zu fördern. Sicherzustellen Sie bevor die Förderung ein Sklave bei Absturz ihres Meisters, dass der erste Meister nicht steigen, um Beschädigungen zu vermeiden.


Wir kehren Wurzel und es beginnt der Dienst : 

# systemctl start postgresql


Dadurch wird sichergestellt, dass der Dienst ordnungsgemäß gestartet : 

# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
   Active: active (exited) since Thu 2016-06-02 12:53:42 CEST; 1min 6s ago
  Process: 8894 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 8894 (code=exited, status=0/SUCCESS)



# ps -u postgres u
USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
postgres   8878  0.0  4.4 227308 21892 ?        S    12:53   0:00 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.
postgres   8879  0.0  1.1 227376  5700 ?        Ss   12:53   0:00 postgres: startup process   recovering 00000001000000000000000
postgres   8880  0.0  0.8 227308  4140 ?        Ss   12:53   0:00 postgres: checkpointer process
postgres   8881  0.0  1.0 227308  5236 ?        Ss   12:53   0:00 postgres: writer process
postgres   8882  0.0  0.6  82252  3316 ?        Ss   12:53   0:00 postgres: stats collector process
postgres   8883  0.0  1.7 238064  8520 ?        Ss   12:53   0:00 postgres: wal receiver process   streaming 0/30003E0


Wenn sie mit unserem Herrn verbindet, finden wir bereits unsere Replikation zwischen dem Master und der erste Sklave ist funktional :

Es verbindet sich mit unserem Meister und verbindet in Postgres Systembenutzer : 

# su - postgres


Dann verbinden mit Postgresql : 

$ psql


Es ermöglicht die erweiterte Anzeige und wir überprüfen unsere Replikation : 

postgres=# \x
Expanded display is on.

postgres=# select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 78879
usesysid         | 16384
usename          | repuser
application_name | postgres02
client_addr      | 10.1.1.90
client_hostname  |
client_port      | 49009
backend_start    | 2016-06-02 12:53:36.641823+02
backend_xmin     |
state            | streaming
sent_CRElocation    | 0/30004C0
write_location   | 0/30004C0
flush_location   | 0/30004C0
replay_location  | 0/30004C0
sync_priority    | 0
sync_state       | async

Unsere Streaming-asynchrone Replikation mit unserer ersten Slave ist gut gemacht. Diese Etappe hat einen Master Replikation /Klassische Slave (ein einzelnes slave asynchrone streaming )

Auf dem zweiten Slave

Wir Redid das gleiche geschehen auf dem ersten Slave offensichtlich Anpassung der Hostname in der Datei recovery.conf und IP-in den Befehl in der Hauptkonfigurationsdatei zu archivieren Adresse, wenn Sie auch auf dieser zweiten Slave Archivierung zu ermöglichen möchten.

Verifikation und Test von unserem Multi master Replikation slawischen

Es verbindet sich mit dem Meister und es angemeldet Benutzer Postgres : 

# su – postgres

Dann verbinden mit Postgresql : 

$ psql


Es ermöglicht die erweiterte Anzeige und wir überprüfen unsere Replikation : 

postgres=# \x
Expanded display is on.

postgres=# select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 78879
usesysid         | 16384
usename          | repuser
application_name | postgres02
client_addr      | 10.1.1.90
client_hostname  |
client_port      | 49009
backend_start    | 2016-06-02 12:53:36.641823+02
backend_xmin     |
state            | streaming
sent_location    | 0/5000140
write_location   | 0/5000140
flush_location   | 0/5000140
replay_location  | 0/5000140
sync_priority    | 0
sync_state       | async
-[ RECORD 2 ]----+------------------------------
pid              | 82725
usesysid         | 16384
usename          | repuser
application_name | postgres03
client_addr      | 10.1.1.199
client_hostname  |
client_port      | 51754
backend_start    | 2016-06-02 14:31:43.759683+02
backend_xmin     |
state            | streaming
sent_location    | 0/5000140
write_location   | 0/5000140
flush_location   | 0/5000140
replay_location  | 0/5000140
sync_priority    | 0
sync_state       | async

So gibt es nun unsere 2 Replikation mit unseren zwei slawischen Servern (postgres02 und Postgres 03).


Noch an Postgresql auf dem Master angeschlossen, es schafft eine Basis (ex : Checkrep ) : 

postgres=# CREATE DATABASE checkrep;


Er prüft, ob die Datenbank auch auf repliziert ist unsere 2 Slawische : 

root@postgres02:~# su - postgres

postgres@postgres02:~$ psql
psql (9.5.3)
Type "help" for help.

postgres=# \l
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 checkrep  | postgres | 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
(4 rows)



root@postgres03:~# su - postgres
postgres@postgres03:~$ psql
psql (9.5.3)
Type "help" for help.

postgres=# \l
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 checkrep  | postgres | 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
(4 rows)

Die Datenbank, die wir auf unsere Master erstellt ist so auch automatisch auf unsere zwei slawische repliziert.


Löschen, da der Meister : 

postgres=# DROP DATABASE checkrep;



Du bist nicht berechtigt Kommentare hinzuzufügen.

Abgerufen von „https://de-wiki.ikoula.com/index.php?title=Replikation_PostgreSQL_slawischen_multi&oldid=11656“