Postgresql replication - Historique des versions

217.174.206.178 le 24 décembre 2014 à 14:03

2014-12-24T14:03:46Z

← Version précédente		Version du 24 décembre 2014 à 14:03
Ligne 111 :		Ligne 111 :

	== Test de la Replication ==		== Test de la Replication ==
			<pre>
			* Nous allons voir et tester la replication entre les deux serveur master/slave (attention le slave ne peut jamais ecrire tant qu'il est slave il est en read-only)

	* ~~Nous allons voir et tester la replication entre les deux~~ serveur master~~/slave (attention le slave ne peut jamais ecrire tant qu~~'~~il est slave il est en read-only)~~		* On se connecte au serveur master et on se positionne avec l'utilisateur system postgres, ensuite on tape ce qui suit :

	* On se connecte au serveur master et on se positionne avec l'utilisateur system postgres, ensuite on tape ce qui suit :

	~~{{{~~
	# psql		# psql
	~~}}}~~		* Nous allons créer une table :

	* Nous allons créer une table :
	~~{{{~~
	CREATE TABLE rep_test (test varchar(40));		CREATE TABLE rep_test (test varchar(40));
	~~}}}~~

	* Nous allons mettre des choses dedans (cette table) :		* Nous allons mettre des choses dedans (cette table) :
	~~{{{~~
	INSERT INTO rep_test VALUES ('data test');		INSERT INTO rep_test VALUES ('data test');
	INSERT INTO rep_test VALUES ('Agarik');		INSERT INTO rep_test VALUES ('Agarik');
Ligne 132 :		Ligne 126 :
	INSERT INTO rep_test VALUES ('pouf');		INSERT INTO rep_test VALUES ('pouf');
	INSERT INTO rep_test VALUES ('blahblah');		INSERT INTO rep_test VALUES ('blahblah');
	~~}}}~~

	* Une fois ces commande passées, nous pouvons quiter via la commande suivante :		* Une fois ces commande passées, nous pouvons quiter via la commande suivante :
	~~{{{~~
	\q		\q
	~~}}}~~

	* Maintenant nous allons regarder en nous connectant sur le slave pour verifier si la table "rep_test" a bien été répliquée ainsi que son contenu :		* Maintenant nous allons regarder en nous connectant sur le slave pour verifier si la table "rep_test" a bien été répliquée ainsi que son contenu :
	* Les actions sont donc a realiser sur le slave en se positionnant avec l'utilisateur system postgres :

	~~{{{~~		* Les actions sont donc a realiser sur le slave en se positionnant avec l'utilisateur system postgres :
	# psql		# psql
	~~}}}~~		* Nous allons verifier que les données sont bien la en faisant un select :

	* Nous allons verifier que les données sont bien la en faisant un select :
	~~{{{~~
	SELECT * FROM rep_test;		SELECT * FROM rep_test;
	test		test
Ligne 157 :		Ligne 144 :
	blahblah		blahblah
	(5 rows)		(5 rows)
	~~}}}~~

	* Si nous avons bien le résultat indiqué c'est que la synchronisation fonctionne correctement.

	* Nous allons valider tout de meme que ne nous pouvons pas écrire depuis le slave (qui doit etre en read-only normalement)		* Si nous avons bien le résultat indiqué c'est que la synchronisation fonctionne correctement.
			* Nous allons valider tout de meme que ne nous pouvons pas écrire depuis le slave (qui doit etre en read-only normalement)
	~~{{{~~
	INSERT INTO rep_test VALUES ('test read-only slave');		INSERT INTO rep_test VALUES ('test read-only slave');
	~~}}}~~

	* Normalement vous devriez avoir le résultat suivant :		* Normalement vous devriez avoir le résultat suivant :
	~~{{{~~
	ERROR: cannot execute INSERT in a read-only transaction		ERROR: cannot execute INSERT in a read-only transaction
	~~}}}~~

	* Une fois les vérifications faites, nous allons supprimer la table rep_test a partir du master :		* Une fois les vérifications faites, nous allons supprimer la table rep_test a partir du master :
	~~{{{~~
	DROP TABLE rep_test ;		DROP TABLE rep_test ;
	~~}}}~~		</pre>

	== Bascule Master/Slave ==		== Bascule Master/Slave ==
			<pre>

			* Le fichier '''trigger''' dont la présence est surveillée par Postgres permet de forcer une bascule manuelle du slave vers le rôle master (il suffit de faire un touch du fichier, a partir du serveur slave)

	~~/!\ '''Attention a ne pas faire sur des serveurs qui seraient en production sans accord d'un responsable''' /!\~~		* Exemple :
	* Le fichier '''trigger''' dont la présence est surveillée par Postgres permet de forcer une bascule manuelle du slave vers le rôle master (il suffit de faire un touch du fichier, a partir du serveur slave)
	* Exemple :
	~~{{{~~
	# touch /opt/applis/postgresql/data/failover_force		# touch /opt/applis/postgresql/data/failover_force
	~~}}}~~		</pre>

	[[Catégorie:software]]		[[Catégorie:software]]

217.174.206.178 le 24 décembre 2014 à 14:00

2014-12-24T14:00:30Z

Voir les modifications

217.174.206.178 le 24 décembre 2014 à 13:57

2014-12-24T13:57:27Z

← Version précédente		Version du 24 décembre 2014 à 13:57
Ligne 3 :		Ligne 3 :
	= Mise en place d'une replication Postgres 9.x en Streaming Replication =		= Mise en place d'une replication Postgres 9.x en Streaming Replication =

	* https://wiki.postgresql.org/wiki/Streaming_Replication		* https://wiki.postgresql.org/wiki/Streaming_Replication
			* PostgreSQL creer un user appelé "postgres" pour la gestion de ces propre bases.
	* PostgreSQL creer un user appelé "postgres" pour la gestion de ces propre bases.

	== Configuration du Master ==		== Configuration du Master ==

217.174.206.178 : Page créée avec « TableOfContents = Mise en place d'une replication Postgres 9.x en Streaming Replication = * https://wiki.postgresql.org/wiki/Streaming_Replication * PostgreSQL cr... »

2014-12-24T13:57:08Z

Page créée avec « TableOfContents = Mise en place d'une replication Postgres 9.x en Streaming Replication = * https://wiki.postgresql.org/wiki/Streaming_Replication * PostgreSQL cr... »

Nouvelle page

[[TableOfContents]]

= Mise en place d'une replication Postgres 9.x en Streaming Replication =

* https://wiki.postgresql.org/wiki/Streaming_Replication

* PostgreSQL creer un user appelé "postgres" pour la gestion de ces propre bases.

== Configuration du Master ==
Lorsque nous allons configurer le serveur master toutes les commandes seront a éxécutées avec l'utilisateur "postgres".

{{{
# su postgres
}}}

* En premier lieu nous allons créer un utilisateur dédié a la réplication (comme dans le cas d'une replication mysql) :

{{{
# psql -c "CREATE USER replicate REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD 'r3pl1c4t10n';"
}}}

* Evidemment il faudra changer le password "r3pl1c4t10n" par celui de votre choix.

* Ensuite, nous allons aller dans le dossier de données postgres :
{{{
# cd /opt/applis/postgresql/data
}}}

* Nous allons modifier le ficher pg_hba.conf (toujours via l'utilisateur postgres) :
{{{
# vi pg_hba.conf
}}}

* Ajouter cette ligne (pas tout en haut) dans le fichier en cours d'édition (en adaptant IP_du_Slave/32) et (replicate : nom donné a l'utilisateur pgsql precedemment créé)
{{{
host replication replicate IP_du_Slave/32 md5
}}}

* Sauvegarder puis fermer l'édition du fichier pg_hba.conf

* Ensuite nous allons éditer le fichier de configuration principal de postgres :
{{{
# vi postgresql.conf
}}}

* Trouver l'emplacement de ces parametres dans le fichier postgresql.conf et changer leur valeurs pour correspondre a ce qu'il est indiqué ci-dessous :

{{{
listen_addresses = 'localhost,ADDRESSE_DE_CE_SERVEUR' # (ou bien *)
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'cd .'
max_wal_senders = 1
hot_standby = on
}}}

* Sauvegarder puis fermer l'édition du fichier
* Relancer le service (sur le master donc) afin d'appliquer les changements effectués.

{{{
# service pgsql restart
}}}

== Configuration du Slave ==

* Si le service est deja installé et tourne, nous allons l'eteindre :
{{{
# service pgsql stop
}}}

* Lorsque nous allons configurer le serveur master toutes les commandes seront a éxécutées avec l'utilisateur "postgres".

{{{
# su postgres
}}}

* Ensuite, nous allons aller dans le dossier de données postgres :
{{{
# cd /opt/applis/postgresql/data
}}}

* Nous allons modifier le ficher pg_hba.conf (toujours via l'utilisateur postgres) :
{{{
# vi pg_hba.conf
}}}

* Ajouter cette ligne (_pas_ tout en haut) dans le fichier en cours d'édition (en adaptant IP_du_Master/32) et (replicate : nom donné a l'utilisateur pgsql precedemment créé) cela premettra au master de se connecter au slave dans le cas d'une bascule du slave vers le role master
{{{
host replication replicate IP_du_Master/32 md5
}}}

* Sauvegarder puis fermer l'édition du fichier pg_hba.conf

* Ensuite nous allons éditer le fichier de configuration principal de postgres :
{{{
# vi postgresql.conf
}}}

* Trouver l'emplacement de ces parametres dans le fichier postgresql.conf et changer leur valeurs pour correspondre a ce qu'il est indiqué ci-dessous :

{{{
listen_addresses = 'localhost,ADDRESSE_DE_CE_SERVEUR' # (ou bien *)
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'cd .'
max_wal_senders = 1
hot_standby = on
}}}

* Sauvegarder puis fermer l'édition du fichier

== Synchronisation des données ==

* Nous allons maintenant procéder a la synchro des données entre le master et le slave (depuis le master et en utilisateur postgres)
{{{
# psql -c "select pg_start_backup('initial_backup');"
# rsync -e ssh -cva --inplace --exclude=*pg_xlog* /opt/applis/postgresql/data root@IP_DU_SLAVE:/opt/applis/postgresql/data
# psql -c "select pg_stop_backup();"
}}}

* Une fois cette synchronisation realisée les données du master sont bien présentes sur le slave.

* Nous allons avoir besoin maintenant de configurer le fichier de recovery (recovery.conf) sur le slave (toujours en tant qu'utilisateur postgres) :
{{{
# cd /opt/applis/postgresql/data
# vi recovery.conf
}}}

* Il faudra y mettre les trois lignes ci-dessous (bien penser a changer l'ip du master ainsi que l'utilisateur et le password) :
{{{
standby_mode = 'on'
primary_conninfo = 'host=IP_DU_MASTER port=5432 user=replicate password=r3pl1c4t10n'
trigger_file = '/opt/applis/postgresql/data/failover_force'
}}}

* Lancer le service (sur le slave cette fois) afin d'appliquer les changements effectués.

{{{
# service pgsql start
}}}

* Une fois les services relancés, il faut donc regarder les logs afin de valider que tout se passe bien et qu'il n'y a aucune erreur (sur le master et le slave).
{{{
# tail -100f /opt/applis/postgresql/data/serverlog
}}}

* Vous devriez voir dans les logs des informations indiquant que le slave se connecte bien au master et inversement que le master voit bien arriver une connexion du slave.

== Test de la Replication ==

* Nous allons voir et tester la replication entre les deux serveur master/slave (attention le slave ne peut jamais ecrire tant qu'il est slave il est en read-only)

* On se connecte au serveur master et on se positionne avec l'utilisateur system postgres, ensuite on tape ce qui suit :

{{{
# psql
}}}

* Nous allons créer une table :
{{{
CREATE TABLE rep_test (test varchar(40));
}}}

* Nous allons mettre des choses dedans (cette table) :
{{{
INSERT INTO rep_test VALUES ('data test');
INSERT INTO rep_test VALUES ('Agarik');
INSERT INTO rep_test VALUES ('tralala');
INSERT INTO rep_test VALUES ('pouf');
INSERT INTO rep_test VALUES ('blahblah');
}}}

* Une fois ces commande passées, nous pouvons quiter via la commande suivante :
{{{
\q
}}}

* Maintenant nous allons regarder en nous connectant sur le slave pour verifier si la table "rep_test" a bien été répliquée ainsi que son contenu :
* Les actions sont donc a realiser sur le slave en se positionnant avec l'utilisateur system postgres :

{{{
# psql
}}}

* Nous allons verifier que les données sont bien la en faisant un select :
{{{
SELECT * FROM rep_test;
test
-----------------
data test
Agarik
tralala
pouf
blahblah
(5 rows)
}}}

* Si nous avons bien le résultat indiqué c'est que la synchronisation fonctionne correctement.

* Nous allons valider tout de meme que ne nous pouvons pas écrire depuis le slave (qui doit etre en read-only normalement)

{{{
INSERT INTO rep_test VALUES ('test read-only slave');
}}}

* Normalement vous devriez avoir le résultat suivant :
{{{
ERROR: cannot execute INSERT in a read-only transaction
}}}

* Une fois les vérifications faites, nous allons supprimer la table rep_test a partir du master :
{{{
DROP TABLE rep_test ;
}}}

== Bascule Master/Slave ==

/!\ '''Attention a ne pas faire sur des serveurs qui seraient en production sans accord d'un responsable''' /!\
* Le fichier '''trigger''' dont la présence est surveillée par Postgres permet de forcer une bascule manuelle du slave vers le rôle master (il suffit de faire un touch du fichier, a partir du serveur slave)
* Exemple :
{{{
# touch /opt/applis/postgresql/data/failover_force
}}}

[[Catégorie:software]]