Installazione di Postgre-XL in CentOS 7

                             

Spieghiamo il funzionamento dei "Componenti"

• Global Transaction Manager (GTM)
  • Il componente Global Transaction Manager ( GTM ) garantisce la coerenza dei dati all'interno del cluster e gestisce le transazioni e la versione delle tabelle e dei record. Il GTM può essere migliorato con uno o più standby che prendono il controllo in caso di guasti.
• Coordinatore (coordinatore)
  • Il coordinatore (coordinator) gestisce tutto ciò che è sessioni utente e interagisce con le GTM nodi e dati. Riceve le query, avvia i piani di esecuzione e li distribuisce ai nodi dei dati. Diversi coordinatori possono essere definiti per distribuire il carico.
• Nodo dati (datanode)
  • Il nodo dei dati (Datanode) memorizza i immagazzina i dati. Esegue anche le query gestite e inviate dai (coordinatori).

Il Cluster
Sono necessari tre nodi per creare un cluster Postgres-XL anche se in realtà solo un nodo può supportare tutti e tre i tipi di componenti. Tuttavia, questo scenario rimuove tutta la logica di distribuzione fornita da Postgres-XL.
Nel caso normale, un cluster minimalista dovrebbe avere un nodo Global Transaction Manager (GTM), un nodo Coordinatore e due datanode.

Prerequisiti per l'installazione di Postgres-XL
Fornisco gli indirizzi IP che ho usato per configurare gli hosts.
Questi IP possono essere modificati se vuoi provare a sperimentare sul tuo cluster.
Ecco la configurazione che abbiamo usato per questo esperimento:

• Nodo 1:
  • Ruolo: GTM (Global Transaction Manager);
  • Hostname: pgxl-1
  • Host: gtm
  • IP: 192.168.1.14
• Nodo 2:
  • Ruolo: coordinatore;
  • Hostname: pgxl-2
  • Host: coord
  • IP: 192.168.1.15
• Nodo 3:
  • Ruolo: datanode
  • Hostname: pgxl-3
  • Host: dn1
  • IP: 192.168.1.16
• Nodo 4:
  • Ruolo: datanode;
  • Hostname: pgxl-4
  • Host: dn2
  • IP: 192.168.1.17
• Nodo 5:
  • Ruolo: Slave di un datanode;
  • Hostname: pgxl-5
  • Host: dn2
  • IP: 192.168.1.18

Software necessario

• S.O.: Centos 7 64bit
• Sorgenti: Postgres-XL

Eseguiremo questo tutorial usando esclusivamente il terminale di CentOS7.

1) Accedere con l'utente root 

$ sudo - su

2) Disattivare SELINUX

# sed -i 's/SELINUX=.*/SELINUX=disabled/' /etc/sysconfig/selinux && setenforce 0

3) Disattivare il Firewall

# systemctl stop firewalld && systemctl disable firewalld

4) Installazione dei pacchetti necessari per la compilazione e installazione di postgres-XL

# yum install ansible readline-devel readline zlib-devel wget zip autoconf automake binutils \
bison flex gcc gcc-c++ gettext libtool make patch pkgconfig redhat-rpm-config rpm-build \
rpm-sign python36 python36-devel

5) Creazione dell'utente postgres

# useradd postgres --shell /bin/bash --home /home/postgres --create-home
# echo -e 'postgres\npostgres\n' | sudo passwd postgres

6) Aggiungere l'utente postgres al gruppo sudo, questa operazione deve essere fatta per tutti  
i server del cluster

# usermod -aG wheel postgre

7) Adesso occorre cambiare l'utente passando da root a postgres

su postgres

8) Creare le password publiche per l'accesso via ssh
Nel server "pgxl-1" occorre generare la chiave di autenticazione per l'ssh,

$ ssh-keygen -t rsa

(Alle richieste premere ENTER confermando tutti i valori standard)

$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

9) Aggiungere le chiavi necessarie per ogni server dentro il file "authorized_keys"

$ vi ~/.ssh/authorized_keys

Dentro dell'editor di testo "vi" digitare la sequenza di tasti "yyp" duplicando la prima linea per il numero di hosts usati.
Appena finita la duplicazione delle linee occorre andare alla fine di ogni linea e al posto di "postgres@pgxl-1" sostituire con il nome di ogni server.

Questo è solo un esempio:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6 dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93 MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-1
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6 dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93 MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-2
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6 dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93 MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-3
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6 dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93 MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-4
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6 dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93 MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-5

10) Dal server "pgxl-1", copiare la directory .ssh nel server pgxl-2, pgxl-3, pgxl-4 e pgxl-5.

$ scp -rp ~/.ssh/ postgres@pgxl-2:~/
$ scp -rp ~/.ssh/ postgres@pgxl-3:~/
$ scp -rp ~/.ssh/ postgres@pgxl-4:~/
$ scp -rp ~/.ssh/ postgres@pgxl-5:~/

11) In tutti i server è necessario cambiare i permessi ai file delle password dell'utente postgres.

$ ssh postgres@pgxl-1 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-2 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-3 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-4 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-5 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

12) Dal server "pgxl-1" provare a connettersi al server pgxl-2, pgxl-3, pgxl-4 e pgxl-5, e accertarsi che non e richiesta la password.

$ ssh postgres@pgxl-2
$ ssh postgres@pgxl-3
$ ssh postgres@pgxl-4
$ ssh postgres@pgxl-5

13) Posizioniamoci dentro la directory /home/postgres del server "pgxl-1".

cd /home/postgres

14) Facciamo il download del pacchetto contente il sorgente di postgres-xl

wget https://sourceforge.net/projects/postgres-xl/files/Releases/Version_9.5r1/postgres-xl-9.5r1.4.tar.gz

15) Copiamo il file appena scaricato in tutti i server del cluster

scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-2:~/ &&\
scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-3:~/ &&\
scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-4:~/ &&\
scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-5:~/

16) Scompattiamo dentro di ogni rispettivo server il file postgres-xl-9.5r1.4.tar.gz

ssh pgxl-1 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-2 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-3 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-4 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-5 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"

17) Adesso per ogni server del cluster configuriamo il codice sorgente e compiliamolo

ssh pgxl-1 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-2 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-3 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-4 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-5 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"

18) Installare Postgres-XL come utente root,
   uscire dall'utente postgres in tutti i servers

exit
ssh root@pgxl-1 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-2 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-3 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-4 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-5 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"

Per default, Postgres-XL è installato nella directory /usr/local/pgsql/.

19) Installare pgxc_ctl solamente sul server "pgxl-1".

Dalla home dell'utente "postgres", entrare nella directory di pgxc_ctl

cd /home/postgres/postgres-xl-9.5r1.4/contrib/pgxc_ctl/
make

20) Una volta compilato il codice sorgente è necessario installare il modulo con l'utente root

 

exit
make install

21) Aggiungere "/usr/local/pgsql/bin" nel PATH per l'utente postgres.
Adesso e necessario editare il file /home/postgres/.bashrc,

vi /home/postgres/.bashrc

e aggiungere alla fine del file la seguente linea:

export PATH=/usr/local/pgsql/bin:$PATH

N.B. questa modifica deve essere fatta per ogni server del cluster.

22) Costruiamo il nostro cluster.
La configurazione del cluster è facilitata dallo strumento pgxc_ctl del nodo 1.

Il nodo crea le proprie configurazioni e le salva dentro il file /home/postgres/pgxc_ctl/pgxc_ctl.conf.
Eventuali modifiche possono essere fatte modificando il file manualmente o tramite il comando pgxc_ctl e nel nostro caso useremo quest'ultimo per generare una versione standard del file di configurazione che personalizzeremo in seguito.

23) Entrare con l'utente postgres
Useremo l'utente postgres dando il comando nel server pgxl-1:

su postgres

24) Entriamo nella directory /home/postgres/

cd /home/postgres/

25) Eseguiamo il comando "pgxc_ctl" per la prima volta.
Il risultato sarà un errore ma creerà la directory "pgxc_ctl"

pgxc_ctl

26) Una volta dentro la console di gestione del cluster digiteremo il comando

PGXL prepare config empty

27) Questo è il momento di personalizzare la configurazione del cluster

vi /home/postgres/pgxc_ctl/pgxc_ctl.conf

28) Modifichiamo solamente questi tre valori:

# user and path
pgxcOwner=postgres                        # L'amministratore del Cluster

# coordinator
coordPgHbaEntries=(192.168.1.0/24)        # Suppone che tutti i coordinatori (master/slave)
                                              accettino la stessa connessione
datanodePgHbaEntries=(192.168.1.0/24)     # Suppone che tutti i coordinatori (master/slave)
                                               accettino la stessa connessione

29) Il prossimo passo è usare pgxc_ctl per aggiungere i nodi del cluster.
Vengono specificati solo i parametri principali, ovvero il nome del nodo, il suo indirizzo, le porte di connessione e la directory di lavoro.
Il primo nodo da aggiungere sarà il nodo che gestisce tutte le transazioni (GTM).

30) Aggiungere il nodo GTM (Global Transaction Manager)

PGXC add gtm master gtm 192.168.1.14 20001 /home/postgres/pgxc/gtm

31) Aggiungere il secondo nodo che sarà il Coordinatore.

PGXC add coordinator master coord1 192.168.1.15 20004 20010 /home/postgres/pgxc/gtm

32) Aggiungere il nodo dati datanode1.

PGXC add datanode master datanode1 192.168.1.16 20008 20012 /home/postgres/pgxc/dn1_master none none none

33) Aggiungere il secondo nodo dati datanode2.

PGXC add datanode master datanode2 192.168.1.17 20009 20013 /home/postgres/pgxc/dn2_master none none none

34) Verificare se tutti i nodi del cluster siano in esecuzione

PGXC monitor all

35) Questo deve essere il risultado mostrato:

Running: gtm master
Running: coordinator master coord1
Running: datanode master datanode1
Running: datanode master datanode2

36) Sul nodo 1, eseguire il seguente comando per creare un database di test nel cluster.

PGXC pgxc_ctl Createdb test

37) Utilizzare lo strumento psql per connettersi al nodo coordinatore (nodo 2).

PGXC psql -h 192.168.1.15 -p 20004 test

38) Creare una tabella hash che verrà distribuita tra i nodi del cluster in base a un hash della colonna id.

test=# create table hashed (id int, surname TEXT) DISTRIBUTE BY HASH(id);
test=# insert into hashed VALUES (1, 'test');

39) Eseguire il seguente comando per ottenere le informazioni dalla tabella.
Noteremo, nell'ultima riga, un'informazione che consente di conoscere il nodo su cui è memorizzata questa tabella.

test=# \d+ hashed

40) Eseguire il seguente comando per elencare le istanze di questa tabella.

test=# select * from hashed;

41) Si noti che l'aggiunta di un altro nodo di dati non ridistribuisce automaticamente i dati già inseriti.
Per verificare ciò, ci connetteremo al nodo 2 usando la console psql.

PGXC psql -h 192.168.1115 -p 20004 test
test=# \d+ hashed

42) Per ridistribuire i dati dalla tabella hash al nuovo nodo, è sufficiente eseguire il seguente comando.

test=# ALTER TABLE hashed ADD NODE (datanode2);

43) Verifichiamo che i dati della tabella hash siano stati ridistribuiti al nuovo nodo di dati.

test=# \d+ hashed

44) Nel caso sia necessario aggiungere un nodo slave al nodo dati, sempre dal nodo GTM, eseguire il comando:

PGXC add datanode slave datanode1 192.168.1.xxx 40101 40111 /home/postgres/pgxc/dn1_slave none /home/postgres/pgxc/dn1_archlog.1

45) Assicuriamoci che il nostro cluster funzioni correttamente.

PGXC monitor all

46) Questo deve essere il risultado mostrato:

Running: gtm master
Running: coordinator master coord1
Running: datanode master datanode1
Running: datanode slave datanode1
Running: datanode master datanode2

47) È importante sapere che un nodo slave funziona nella replica dei dati di forma sincrona:

test=# EXECUTE DIRECT ON(datanode1) 'SELECT client_hostname, state, sync_state FROM pg_stat_replication';

48) Simulazione di un failover

Aggiungiamo alcuni dati alla tabella hash per convalidare questa replica.

test=# INSERT INTO hashed SELECT generate_series(1001,1100), 'foo';

49) Per trovare la distribuzione dei dati in base ai diversi nodi di dati, eseguire il comando seguente.

test=# SELECT p.node_host, p.node_name, count(*) FROM hashed h, pgxc_node p where h.xc_node_id = p.node_id GROUP BY p.node_name, p.node_host;

50) Per testare la tolleranza di errore e vedere l'interesse del nodo dati slave, proponiamo di arrestare il nodo dati 1 eseguendo il seguente comando.

PGXC stop -m immediate datanode master datanode1

51) L'esecuzione di query sul cluster è ora impossibile perché mancano i dati (53 istanze non sono più disponibili). Per verificare ciò, eseguire la seguente riga di comando.

test=# SELECT p.node_host, p.node_name, count(*) FROM hashed h, pgxc_node p where h.xc_node_id = p.node_id GROUP BY p.node_name, p.node_host;

52) Poiché Postgres-XL non supporta il failover automatico ma deve essere esplicitamente indirizzato. Esegui il seguente comando.

PGXC failover datanode datanode1

53) Ora controlliamo che la query precedente funzioni correttamente.

test=# SELECT p.node_host, p.node_name, count(*) FROM hashed h, pgxc_node p where h.xc_node_id = p.node_id GROUP BY p.node_name, p.node_host;

54) Il nodo dati slave ora ha preso il posto del nodo dati master. Questo può essere confermato attraverso i risultati della seguente query.

test=# SELECT oid, * FROM pgxc_node;

55) Va notato che il nodo dati originale 1 è stato completamente rimosso dal cluster.
Non esiste più nulla che appartiene a lui nel file di configurazione pgxc_ctl.conf.
Un modo per riutilizzarlo se disponibile è impostarlo a sua volta come slave del nuovo nodo dati 1.
Eseguire la riga di comando successiva.

PGXC add datanode slave datanode1 192.168.1.16 20008 20012 /home/postgres/pgxc/dn1_master none /home/postgres/pgxc/dn1_archlog.1

56) Per assicurarsi che il cluster si trovi nello stato desiderato, eseguire la seguente riga di comando

PGXC monitor all

visualizzeremo lo stato del cluster come mostrato in basso:

Running: gtm master
Running: coordinator master coord1
Running: datanode master datanode1
Running: datanode slave datanode1
Running: datanode master datanode2

Abbiamo visto attraverso questo tutorial l'installazione di Postgres-XL, una versione distribuita del database PostgreSQL, facendo esperienza su un cluster di test composto da cinque nodi.

Questa versione offre alcune caratteristiche interessanti come, per esempio la (distribuzione di dati e di query distribuite in particolare).
Tuttavia, notiamo alcuni svantaggi dovuti, ad esempio, al recupero degli errori in cui occorre gestirle manualmente.

In termini di prospettive, sarebbe interessante controllare Postgres-XL:

• robustezza durante un aumento del carico orizzontale;
• funzionamento su un lungo periodo;
• l'implementazione di un bilanciamento del carico;
• tolleranza d'errore quando si perdono più nodi.