Bucardo: Multimaster-Replikation

Während er gequält wurde, schaufelte er eine Menge Artikel und beschloss, einen detaillierten Kommentar zum Handbuch zu verfassen. Darüber hinaus gibt es nur sehr wenige Informationen zur Konfiguration von Multimaster auf Russisch, und es ist irgendwie stückweise.

Ein bisschen einleitend. Damit Bucardo funktioniert, müssen wir:

1) Ihm mitteilen, welche teilnehmenden Datenbanken auf welchen Servern existieren.

2) Sagen Sie ihm, welche Tabellen an der Replikation beteiligt sind.

Achtung: Wenn die Entwickler der Anwendung eine neue Tabelle hinzufügen, müssen wir bucardo darüber informieren. Gleiches gilt für das Ändern des Schemas vorhandener Tabellen.

3) Sagen Sie ihm, welche Tabellengruppen existieren und welche Tabellen in welche Gruppen fallen. Gruppen werden benötigt, wenn verschiedene Tabellen zwischen verschiedenen Servern repliziert werden müssen. Es ist bequemer, mit einer Gruppe zu arbeiten, als sie einzeln anzugeben (sehr ähnlich wie bei Gruppen in Nagios).

4) Sagen Sie ihm, welche Datenbankgruppen existieren. Das Ziel ist das gleiche wie für die Tabellen.

Fahren wir mit der Installation fort. Option für Debian 7. Es versteht sich, dass die Pakete postgresql-9.1 und postgresql-client-9.1 bereits installiert sind.

Vorbereitende Vorbereitung

Die Server werden als Knoten1 und Knoten2 bezeichnet . Sie müssen außerdem überprüfen, ob alle beteiligten PostreSQL-Server externe Schnittstellen überwachen:

# netstat -plnt4 | grep 5432
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      12345/postgres

Installieren Sie das Bucardo-Paket und die PL / Perl-Unterstützung für PostgreSQL auf jedem Server:

# apt install bucardo postgresql-plperl-9.1

Wir aktivieren auf jedem der Server:

# sed -i 's/ENABLED=0/ENABLED=1/' /etc/default/bucardo

Die Paketbetreuer haben aus irgendeinem Grund nicht davon ausgegangen, ein Verzeichnis unter der PID zu erstellen. Daher werden wir es auf jedem der Server selbst erstellen:

# mkdir /var/run/bucardo

Wir stellen sicher, dass wir über den TCP-Socket auf jedem der Server eine Verbindung zum DBMS herstellen können:

# psql -U postgres -h 127.0.0.1

Wenn Sie sich nicht erinnern Ihr Kennwort ein , dann die einfachen Anweisungen hier .

Wenn PG keine Anforderungen von einer bestimmten Adresse eines bestimmten Benutzers annehmen möchte, konfigurieren Sie /etc/postgresql/9.1/main/pg_hba.conf.

Anschließend wird die Datenbank initialisiert. Es wird vom Benutzer postgres erstellt, aber mit dem Benutzer bucardo gefüllt, damit Sie auf ein Verbindungsproblem stoßen können.
Um dies zu vermeiden, fügen wir im Voraus eine Zeile in /etc/postgresql/9.1/main/pg_hba.conf ein. Darüber hinaus verweist Bucardo bereits in diesem Prozess nicht nur auf seinen Clusterknoten, sondern auch auf das erste Paar. Deshalb vergessen wir es auch nicht. Wenn Sie mehr Server im Cluster haben, vergessen Sie diese nicht. Auf jedem der Server:

host    all             bucardo         127.0.0.1/32              trust
host    all             bucardo         SECOND.NODE.IP.ADDRESS/32 password

Danach starten Sie das DBMS neu:

# pg_ctlcluster 9.1 main restart

Bucardo-Installation

Das Dienstprogramm bucardo_ctl wurde in neueren Versionen von Debian durch bucardo ersetzt, daher werden wir es verwenden.

Initialisieren Sie die Datenbank:

# bucardo install

Der Dialog sieht ungefähr so ​​aus:

# bucardo install
This will install the bucardo database into an existing Postgres cluster.
Postgres must have been compiled with Perl support,
and you must connect as a superuser
Current connection settings:
1. Host:           localhost
2. Port:           5432
3. User:           postgres
4. Database:       postgres
5. PID directory:  /var/run/bucardo
Enter a number to change it, P to proceed, or Q to quit: P
Password for user postgres:
Postgres version is: 9.1
Password for user postgres:
Creating superuser 'bucardo'
Password for user postgres:
Attempting to create and populate the bucardo database and schema
Password for user postgres:
Database creation is complete
Updated configuration setting "piddir"
Installation is now complete.
If you see errors or need help, please email bucardo-general@bucardo.org
You may want to check over the configuration variables next, by running:
bucardo show all
Change any setting by using: bucardo set foo=bar

Während des Initialisierungsprozesses wurde die Datenbank aus der Datei /usr/share/bucardo/bucardo.schema erstellt, sodass Sie sie nicht wie in den Handbüchern früherer Versionen beschrieben mit Ihren Händen ausfüllen müssen.

Bucardo ist installiert, Sie können es ausführen:

# bucardo start

Replikationskonfiguration

Vor dem Einrichten der Replikation werden Testbasen erstellt, die repliziert werden.
Auf jedem der Server:

# psql -U postgres -c "CREATE DATABASE mydb;"
# psql -U postgres mydb -c "CREATE TABLE mytable ( num123 integer PRIMARY KEY, abc varchar(10) );"

Ein weiterer wichtiger Punkt in Bezug auf die Sicherheit . Nach dem Hinzufügen der replizierten Datenbank zur Konfiguration gibt Bucardo das Benutzerkennwort in die Datenbank ein. Und da er es während der Installation nicht angefordert hat, hat er es genau so gemacht wie der Benutzer von postgres. Mit anderen Worten, das Passwort des Superuser wird in der bucardo-Datenbank im Klartext gespeichert, was etwas gefährlich ist.

Deshalb werden wir ihm ein anderes Passwort geben. Auf jedem der Server:

# psql -U postgres -c "ALTER USER bucardo WITH PASSWORD 'eiP4uSash5';"

Als nächstes geben wir Bucardo Informationen darüber, wie Sie eine Verbindung zu der Datenbank herstellen, die wir replizieren werden. Ich bin kein Fan von Unix-Sockets unter Hochlastbedingungen (ein separates Gesprächsthema). Selbst wenn es lokal ist, geben wir einen TCP-Socket an.

ACHTUNG: Wir machen das auf dem node1 Server. Im Allgemeinen arbeiten wir weiterhin nur mit node1, bis geklärt ist, was auf beiden zu tun ist.

Fügen Sie die lokale (mydb_node1) und die Remote-Kopie (mydb_node2) vom node2-Server hinzu:

# bucardo add database mydb_node1 dbname=mydb dbhost=127.0.0.1 dbuser=bucardo dbpass=eiP4uSash5
Added database "mydb_node1"

# bucardo add database mydb_node2 dbname=mydb dbhost=node2.example.com dbuser=bucardo dbpass=eiP4uSash5
Added database "mydb_node2"

Hier:

mydb_nodeX ist die interne Bezeichnung der Datenbank. Dieser Name wird von Bucardo in der internen Arbeit mit der Basis verwendet.
dbname = mydb ist der tatsächliche Datenbankname in PostgreSQL, auf den mydb_nodeX verweist.
dbuser = bucardo - unter dem sich Bucardo mit dem DBMS verbindet, um mit dieser Datenbank zu arbeiten.

Wir können das Ergebnis so sehen:

# bucardo list database
Database: mydb_node1  Status: active  Conn: psql -p  -U bucardo -d mydb -h 127.0.0.1
Database: mydb_node2  Status: active  Conn: psql -p  -U bucardo -d mydb -h node2.example.com

Diese Einstellungen werden aus der DB-Tabelle der bucardo-Datenbank übernommen, in der sich das oben genannte Passwort befindet:

# psql -U postgres bucardo -c "SELECT name,dbname,dbhost,dbuser,dbpass,status FROM db;"
    name    | dbname |      dbhost       | dbuser  |   dbpass   | status
------------+--------+-------------------+---------+------------+--------
 mydb_node1 | mydb   | 127.0.0.1         | bucardo | eiP4uSash5 | active
 mydb_node2 | mydb   | node2b.forbet.net | bucardo | eiP4uSash5 | active
(2 rows)

Jetzt müssen wir die Tabelle hinzufügen, die wir zwischen ihnen replizieren werden. In den meisten Fällen wird die gesamte Datenbank repliziert, sodass alles auf einmal hinzugefügt wird (eine Gruppe von Tabellen (Herde) wird automatisch erstellt). Wenn sich die Entwickler eine neue Tabelle einfallen lassen, fügen wir sie später einfach der Gruppe hinzu, und alles funktioniert, da die weiteren Einstellungen die gesamte Gruppe betreffen.

# bucardo add table all --db=mydb_node1 --herd=mydb_herd
Creating herd: mydb_herd
Added table public.mytable to herd mydb_herd
New tables added: 1

Hier:

--herd = mydb_herd - der Name der Tabellengruppe, damit Sie später die Synchronisation nicht für jede einzelne, sondern für die gesamte Menge konfigurieren können.

Und sofort können wir es sehen:

# bucardo list tables
1. Table: public.mytable  DB: mydb_node1  PK: num123 (int4)
Здесь нужно заострить внимание на PK. Bucardo, похоже, не работает с таблицами без первичных ключей. Вы потом не сможете синк сделать.

Und die Gruppe ist auch sichtbar:

# bucardo list herd
Herd: mydb_herd  DB: mydb_node1  Members: public.mytable

Gleiches gilt für Sequenzen. In unserem Beispiel sind sie nicht, aber plötzlich nutzt jemand. Wir werden für sie keine eigene Gruppe gründen, um dies nicht zu erschweren. Die Wahrscheinlichkeit, dass Tabellen in eine Richtung und Sequenzen in eine andere repliziert werden, ist äußerst gering. Geben Sie daher eine Gruppe für Tabellen und Sequenzen an:

# bucardo add sequence all --db=mydb_node1 --herd=mydb_herd
Sorry, no sequences were found
New sequences added: 0

Unsere nächste Aufgabe besteht darin, eine Replikationsgruppe zu erstellen. In dieser Gruppe werden wir sagen, welche Basis die Quelle und welche der Empfänger der Daten sein wird. Erstellen Sie zunächst die Gruppe selbst, solange sie leer ist:

# bucardo add dbgoup other_mydb_servers
Created database group "mydb_servers_group"

Wir fügen der Gruppe beide Server hinzu und geben an, wer welche Rolle spielt. Dies ist der einzige Punkt, an dem sich die Master-Slave-Konfiguration von der Master-Master-Konfiguration unterscheidet .

Anfangs könnte man denken, dass die Quelle die Quelle und das Ziel der Empfänger ist. In der Tat ist dies nicht ganz richtig. Quelle ist eine Person, die sowohl als Quelle als auch als Empfänger fungiert, und Ziel ist nur ein Empfänger.

Das heißt, wenn wir Master-Slave haben, geben wir eine Quelle und das zweite Ziel an. Und wenn wir Master-Master haben, dann sind beide Quelle und Target'ov überhaupt nicht.

Option für MASTER -> SLAVE:

# bucardo add dbgroup mydb_servers_group mydb_node1:source
Added database "mydb_node1" to group "mydb_servers_group" as source
# bucardo add dbgroup mydb_servers_group mydb_node2:target
Added database "mydb_node2" to group "mydb_servers_group" as target

Option für MASTER <-> MASTER:

# bucardo add dbgroup mydb_servers_group mydb_node1:source
Added database "mydb_node1" to group "mydb_servers_group" as source
# bucardo add dbgroup mydb_servers_group mydb_node2:source
Added database "mydb_node2" to group "mydb_servers_group" as source

Das ist alles! Wir haben geschrieben, was die Grundlagen sind. Es wird geschrieben, welche Tabellen sie haben. Es steht geschrieben, wer in welcher Gruppe ist. Es bleibt der letzte Schliff zu sagen - zu sagen, welche Gruppe von Tabellen zwischen den Basen welcher Gruppe "laufen" wird. Mit anderen Worten, erstellen Sie eine "Synchronisierung":

# bucardo add sync mydb_sync herd=mydb_herd dbs=mydb_servers_group
Added sync "mydb_sync"

Wir können sehen, was wir haben:

# bucardo list sync
Sync: mydb_sync  Herd: mydb_herd [Active]
  DB group mydb_servers_group: mydb_node1 (source) mydb_node2 (source или target - как настроили)

Starten Sie Bucardo nach dem Ändern der Einstellungen neu:

# bucardo restart

========

Überprüfung: Führen Sie auf dem ersten Knoten 1 Folgendes aus:

# psql -U postgres mydb -c "INSERT INTO mytable VALUES (1, 'a');"

und auf dem zweiten node2 prüfen wir:

# psql -U postgres mydb -c "SELECT * FROM mytable;"

Wer einen Multimaster gemacht hat, muss das in umgekehrter Richtung prüfen. Erstellen Sie auf Knoten2 und testen Sie auf Knoten1.

========

Fragen, die die meisten Leute haben werden:

1) Was passiert mit der Tabelle auf der Zielbasis, wenn die Tabelle auf der Quellbasis geändert wurde, während Bucardo ausgeschaltet war oder das Netzwerk nicht verfügbar war?

Antwort: alles ok Beim Start oder wenn ein Netzwerk angezeigt wird, überträgt Bucardo Daten auf den Zielserver. So kann der Zielserver nach Belieben ausfallen. Die einzige Voraussetzung ist, dass es dasselbe Datenschema (Tabellenstruktur) wie das erste hat.

__

2) Wenn die Basis groß ist (Zehn bis Hunderte von Gigabyte), bricht Bucardo ab und synchronisiert nicht mit dem Ende. Wie zu sein

Antwort: Deaktivieren Sie die Synchronisierung. Bucardo muss jedoch für die Quelldatenbank aktiviert sein, damit Anforderungen protokolliert werden können.

bucardo update sync mydb_sync status = inactive (für Multimaster auf allen Knoten)
Führen Sie als Nächstes pg_dump / pg_restore mit Ihren Händen aus und bringen Sie die Synchronisierung wieder in den aktiven Modus (für Multimaster zuerst auf den Modus, in dem die neuen Anforderungen nach dem Start des Dumps ausgeführt wurden).

Jetzt auch beliebt: