---
# System prepended metadata

title: 'TP3: Réplication'

---

# TP3: Réplication

## Binôme:

*   Bunel Maxime
*   Molinares Diogenes

#### Quelle est la différence entre une réplication logique et une réplication physique ?

> La réplication logique est une méthode permettant de répliquer des données au niveau objet ainsi que les modifications apportées à ces objets, ceci basé sur leur identité de réplication (habituellement la clé primaire). L'utilisation du terme « réplication logique » est faite en opposition à la réplication physique qui elle, utilise l'adresse exacte des blocs couplée avec une réplication octet par octet.

#### Qu’est-ce qu’un réplication en WAL shipping ?

![](https://i.imgur.com/dpXey8E.png)


> Pour que les données soient toujours synchronisées, la reine envoie directement les journaux WAL à la princesse . La reine  peut soit copier les journaux sur le stockage des serveurs princesse, soit simplement partager le stockage avec eux.
> 
> Tous les journaux WAL ont une capacité de stockage maximale de 16 Mo et ne sont expédiés qu'après avoir atteint la valeur seuil. Cela peut entraîner un retard dans le processus de réplication et augmenter les risques de perte de données en raison d'une éventuelle panne du maître.

[Source](https://hevodata.com/learn/postgres-wal-replication/#file)


#### Qu’est-ce qu’une réplication en mode “streaming” ?

![](https://i.imgur.com/8IgHmYA.png)

> Les serveurs de base de données diffusent les enregistrements WAL par morceaux afin de garantir que les données sont toujours synchronisées. Les serveurs princesse reçoivent les morceaux WAL en établissant une connexion avec le serveur reine. L'avantage de la diffusion en continu des enregistrements WAL est qu'elle n'attend pas que la capacité soit pleine, ceux-ci sont diffusés immédiatement. Cela permet de maintenir le serveur de secours à jour.

[Source](https://hevodata.com/learn/postgres-wal-replication/#wal)

#### Une réplication synchrone peut-elle fonctionner en WAL shipping ?

> Oui 

[Source](https://www.pgcon.org/2008/schedule/attachments/61_Synchronous%20Log%20Shipping%20Replication.pdf)


####  Quels sont les inconvénients d’une réplication synchrone ?

> Temps de réponse augmentées
 
 [Source](https://sort.veritas.com/public/documents/vis/7.0/windows/productguides/html/vvr_admin/ch01s05s01s02.htm)



## Replication

:warning: **pgbackrest doit être à la même version sur les deux dépôts** :warning: 

:warning: **Les deux cluster doivent avoir le même nom (Pour notre exemple 'base')**  :warning: 

#### Creation des clés ssh 

> sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh

> sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa        -t rsa -b 4096 -N ""

#### SSH passwordless 

Repository
``` 
(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && 
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' &&
sudo ssh -i .ssh/tiw3-asbd-postgres.pem ubuntu@192.168.73.231 
sudo cat /var/lib/postgresql/.ssh/id_rsa.pub) |        
sudo tee -a /var/lib/postgresql/.ssh/authorized_keys
```

Backup
```
> (echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' &&
echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' &&
sudo ssh -i .ssh/tiw3-asbd-postgres.pem ubuntu@192.168.73.204 
sudo cat /var/lib/postgresql/.ssh/id_rsa.pub) |        
sudo tee -a /var/lib/postgresql/.ssh/authorized_keys
```

### Hot Standby

Modifier le fichier `/etc/pgbackrest/pgbackrest.conf`

```bash=
[global]
repo1-path=/var/lib/pgbackrest
log-level-file=detail
repo1-host=192.168.73.204

[base]
pg1-path=/var/lib/postgresql/14/base
repo1-host-user=postgres
```

Creation du cluster reine sur la machine princesse

`sudo pg_createcluster 14 base`

Restoration du cluster base sur standby

```bash=
sudo -u postgres pgbackrest --stanza=base --delta --type=standby restore

sudo -u postgres cat /var/lib/postgresql/14/base/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.

# Recovery settings generated by pgBackRest restore on 2022-06-19 12:39:35
restore_command = 'pgbackrest --stanza=base archive-get %f "%p"'
```


### Streaming Replication

##### Creation d'un utilisateur repl avec les droit de replication sur la machine princesse

```sql=
sudo -u postgres psql

create user repl password 'password' replication
```

##### Ajout du cluster princesse sur le cluster reine

```bash=
sudo nano /etc/postgresql/14/base/pg_hba.conf 
```

```
host    replication     repl        192.168.73.231/32      md5
```
#### Redémarrage du cluster reine

`sudo pg_ctlcluster 14 base reload`

#### Sur la machine princesse

`sudo nano /etc/pgbackrest/pgbackrest.conf`

```bash=
[global]
log-level-file=detail
repo1-host=192.168.73.204

[base]
pg1-path=/var/lib/postgresql/14/base
repo1-host-user=postgres
recovery-option=primary_conninfo=host=192.168.73.204 port=5432 user=repl
```

#### Conigurer un mot de passe sur le cluster princesse

```bash=
sudo -u postgres sh -c 'echo \
  "193.168.73.204:*:replication:repl:password" \ 
  /var/lib/postgresql/.pgpass'
  
sudo -u postgres chmod 600 /var/lib/postgresql/.pgpass
```

#### Restore le cluster reine sur le cluster princesse 

```bash=
sudo -u postgres pgbackrest --stanza=base --delta --type=standby restore
sudo pg_ctlcluster 14 base start
```
#### Vérifier les logs
```bash=
sudo -u postgres cat /var/log/postgresql/postgresql-14-base.log

2022-06-19 16:52:23.217 UTC [499177] LOG:  starting PostgreSQL 14.2(Ubuntu 14.2-1.pgdg20.04+1+b1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit
2022-06-19 16:52:23.219 UTC [499177] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2022-06-19 16:52:23.225 UTC [499177] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5433"
2022-06-19 16:52:23.267 UTC [499178] LOG:  database system was interrupted; last known up at 2022-06-19 16:47:30 UTC
2022-06-19 16:52:26.072 UTC [499178] LOG:  entering standby mode
2022-06-19 16:52:26.797 UTC [499178] LOG:  restored log file "00000001000000000000000C" from archive
2022-06-19 16:52:27.141 UTC [499178] LOG:  redo starts at 0/C000028
2022-06-19 16:52:27.148 UTC [499178] LOG:  consistent recovery state reached at 0/C000170
2022-06-19 16:52:27.149 UTC [499177] LOG:  database system is ready to accept read-only connections
2022-06-19 16:52:27.911 UTC [499192] LOG:  started streaming WAL from primary at 0/D000000 on timeline 1

```

#### Basculer en mode synchrone

On dois spécifier un nom pour le cluster princess

- Modifier le fichier pgbackrest.conf et ajouter  application_name

```bash=
recovery-option=primary_conninfo=host=192.168.73.204 port=5433 
user=repl password=password application_name=princess
```

##### Sur le cluster reine

- dans Postgresql.conf modifier la ligne

```bash=
synchronous_standby_names = 'princess'  
# standby servers that provide sync rep
```

Puis redémarrer postgresql

```bash=
sudo pg_ctlcluster 14 base stop
sudo pg_ctlcluster 14 base start
```


### Vérification

#### Ajout d'une vue
 - Connexion au la base reine

`psql -U pgbench -h localhost -p 5433`

```sql=
\c benchdb


create view repl-view as 
select count(*) from pgbench_accounts;

select * from replview;

```
Resultat :
```
  count  
---------
 1000000
(1 row)
```

- Sur le cluster princesse

`psql -U pgbench -h localhost -p 5433`
```sql=
\c benchdb
select * from replview;
```
Resultat : 
```
  count  
---------
 1000000
(1 row)
```

#### Exemple de supression de tuple en mode asynchrone

- Sur le cluster Reine

```sql=
delete from pgbench_accounts where bid=2;

DELETE 100000
```

- Sur le cluster Princesse

```sql=
select * from replview;
```
Resultat :

```
 count  
--------
 900000
(1 row)
```

#### Exemple de supression de tuple en mode synchrone

- Sur le cluster Reine

```sql=
delete from pgbench_accounts where bid=3;

DELETE 100000
```

- Sur le cluster Princesse

```sql=
select * from replview;
```
Resultat :

```
 count  
--------
 800000
(1 row)
```

On remarque que le temps d'execution de cette modification est beaucoup plus longue en mode synchrone.




