Deploy do cluster Postgres-XL

Admin -  Abril 11, 2019

Cover Image
Tutorial de como instalar um cluster PostgreSQL-XL

Componentes

  • Global Transaction Manager (GTM) - O GTM garante a consistência dos dados dentro do cluster e gerencia transações e a versão de tabelas e registros. O GTM pode ser melhorado com um ou mais standbys que assumem o controle em caso de falhas.
  • Coordenador - O coordenador gerencia todas as sessões do usuário e interage com os nós e dados do GTM. Recebe consultas, lança planos de execução e os distribui para os nós de dados. Vários coordenadores podem ser definidos para distribuir a carga.
  • Nó de dados (datanode) - O datanode armazena os dados. Também executa consultas que são gerenciadas e enviadas por coordenadores.
  • Cluster - Três nós são necessários para criar um cluster do Postgres-XL, apesar que na realidade apenas um nó pode suportar todos os três tipos de componentes. No entanto, esse cenário remove toda a lógica de distribuição fornecida pelo Postgres-XL. No caso normal, um cluster minimalista teria um nó Gerenciador de Transações Globais (GTM), um nó Coordenador e dois datanodes.

Para o tutorial usaremos

1 GTM
2 Coordenadores
2 Datanodes

Pré-requisitos

-- Como indicação, fornecemos os endereços IP que usamos. Estes podem ser alterados se você quiser experimentar em seu cluster. Aqui está a decomposição que selecionamos para este experimento.

OBS. è necessário configurar o arquivo /etc/hosts de cada servidor com a configuração abaixo

  • 192.168.22.101 prod_bd_101

  • 192.168.22.102 prod_bd_102

  • 192.168.22.103 prod_bd_103

  • 192.168.22.104 prod_bd_104

  • Nó 1:
    função: GTM (Global Transaction Manager);
    hostname: prod_bd_101
    host: gtm
    IP: 192.168.22.101

  • Nó 2:
    -- função: coordenador1 master;
    -- função: datanode1 master;
    -- hostname: prod_bd_102
    -- host: coord1
    -- Host: dn1
    -- IP: 192.168.22.102

  • Nó 3:
    -- função: coordenador2 master;
    -- função: datanode2 master;
    -- hostname: prod_bd_103
    -- host: coord2
    -- Host: dn2
    -- IP: 192.168.22.103

  • Nó 4 (Opcional):
    -- função: datanode slave;
    -- hostname: prod_bd_104
    -- Host: dn1_slave
    -- IP: 192.168.22.104

  • Software necessário
    --S.O.: Centos 7 64bit
    --Código fonte: Postgres-XL

-- Faça o login com o usuário root $ sudo - su

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

-- Desativar o serviço do Firewall # systemctl stop firewalld && systemctl disable firewalld

-- Instalação dos pacotes necessários para a compilação e instalação do 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

-- Criar as senhas publicas para o acesso via ssh do usuário root No servidor "prod_bd_101", precisamos gerar a chave de autenticação para o ssh, # ssh-keygen -t rsa (Nas solicitações, pressione ENTER confirmando todos os valores padrão) # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

-- Adicione as chaves necessárias para cada servidor no arquivo "authorized_keys" # vi ~/.ssh/authorized_keys

dentro do editor vi digite a sequência de teclas ypp duplicando a primeira linha para o número de servidores usados.

-- Assim que a duplicação das linhas terminar, vá para o final de cada linha e, em vez de "root@prod_bd_101", substituiremos o nome de cada servidor. exemplo: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXMyFVIfirLqYIitbEJKow/xu1bYWKsi/YjCRyaEjR6cjlhrd5aeE3AAeeHcXJyj229JEP6ClJs7OHmFa3q9J5ZZrCTutVDq2BGbr1WjkEvhF5mkzXNd+BRhNdzwhLV+7ISQs0NMpN4FUGS5mfR4pQcsqgbOU12fgl5Aqh5mpLP0KKLTIaIZNzeRoXWsvwnIBWG7dnq+kbK9D4Vzn5fkN5UyLFbLuItWkkVgkaJYxvBQdQR98FiaEfj+o13OnqVDI6h18LrD74yZh7BjKt4MzDxzR3MGUewyonBUKJ8V9w1n+XxiW6JCZk5kVd3GhfjyV6PqIUy5WlZlyirUQI05vF root@prod_bd_101 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXMyFVIfirLqYIitbEJKow/xu1bYWKsi/YjCRyaEjR6cjlhrd5aeE3AAeeHcXJyj229JEP6ClJs7OHmFa3q9J5ZZrCTutVDq2BGbr1WjkEvhF5mkzXNd+BRhNdzwhLV+7ISQs0NMpN4FUGS5mfR4pQcsqgbOU12fgl5Aqh5mpLP0KKLTIaIZNzeRoXWsvwnIBWG7dnq+kbK9D4Vzn5fkN5UyLFbLuItWkkVgkaJYxvBQdQR98FiaEfj+o13OnqVDI6h18LrD74yZh7BjKt4MzDxzR3MGUewyonBUKJ8V9w1n+XxiW6JCZk5kVd3GhfjyV6PqIUy5WlZlyirUQI05vF root@prod_bd_102 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXMyFVIfirLqYIitbEJKow/xu1bYWKsi/YjCRyaEjR6cjlhrd5aeE3AAeeHcXJyj229JEP6ClJs7OHmFa3q9J5ZZrCTutVDq2BGbr1WjkEvhF5mkzXNd+BRhNdzwhLV+7ISQs0NMpN4FUGS5mfR4pQcsqgbOU12fgl5Aqh5mpLP0KKLTIaIZNzeRoXWsvwnIBWG7dnq+kbK9D4Vzn5fkN5UyLFbLuItWkkVgkaJYxvBQdQR98FiaEfj+o13OnqVDI6h18LrD74yZh7BjKt4MzDxzR3MGUewyonBUKJ8V9w1n+XxiW6JCZk5kVd3GhfjyV6PqIUy5WlZlyirUQI05vF root@prod_bd_103 -- A partire do servidor "prod_bd_101", copie o diretório .ssh para os servidores prod_bd_102 e prod_bd_103 # scp -rp ~/.ssh/ root@prod_bd_102:~/ # scp -rp ~/.ssh/ root@prod_bd_103:~/`

-- Em todos os servidores, é necessário alterar as permissões para os arquivos de senha do usuário root. # ssh root@prod_bd_101 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys" # ssh root@prod_bd_102 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys" # ssh root@prod_bd_103 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

-- No servidor "prod_bd_101", tente conectar-se ao servidor prod_bd_102 e prod_bd_103, e verifique se a senha não é necessária # ssh root@prod_bd_101 # ssh root@prod_bd_102 # ssh root@prod_bd_103

-- Criando o usuário postgres # useradd postgres --shell /bin/bash --home /home/postgres --create-home # echo -e 'postgres\npostgres\n' | sudo passwd postgres

-- Adicionamos o usuário postgres ao grupo sudo, essa operação deve ser feita para todos os servidores no cluster # usermod -aG wheel postgres

-- Agora precisamos mudar o usuário root para o postgres (somente na máquina prod_bd_101) su postgres

-- Criar as senhas publicas para o acesso via ssh No servidor "prod_bd_101", precisamos gerar a chave de autenticação para o ssh, $ ssh-keygen -t rsa (Nas solicitações, pressione ENTER confirmando todos os valores padrão) $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

-- Adicione as chaves necessárias para cada servidor no arquivo "authorized_keys" $ vi ~/.ssh/authorized_keys

dentro do editor vi digite a sequência de teclas ypp duplicando a primeira linha para o número de servidores usados.

-- Assim que a duplicação das linhas terminar, vá para o final de cada linha e, em vez de "postgres@prod_bd_101", substituiremos o nome de cada servidor. exemplo: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2a3HLxE1oldA8dGM3L83ESvslffQZ5uzsTE+Qwhem2EWQYKp4izSCRPqFqMGJk53aVGAOP4T+h2Hb43q5bGaRpGA giwwp4W6nbtq5835IftGGaDNaIDefibWJszAmrcsHSMpOXmF596Z5PoujPG4AXdwEU1XzoMj3O9sR+iE5IItxdw+EDiMOjL5LGHyMjjTC6l9zHsu83y93JaoUONpH4F /jpIgccZ0Xo1J+UeKr4C3SXu3S7Ra4rBcEG/zAM05zliyHo+7c78bWZbg6V5jOAa+oBJcXsQCp+hIicKW9IcoPRFjoe9WeHvq92r0oZnW1+cDGl+MLedhM0+pI9hil postgres@prod_bd_101 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2a3HLxE1oldA8dGM3L83ESvslffQZ5uzsTE+Qwhem2EWQYKp4izSCRPqFqMGJk53aVGAOP4T+h2Hb43q5bGaRpGA giwwp4W6nbtq5835IftGGaDNaIDefibWJszAmrcsHSMpOXmF596Z5PoujPG4AXdwEU1XzoMj3O9sR+iE5IItxdw+EDiMOjL5LGHyMjjTC6l9zHsu83y93JaoUONpH4F /jpIgccZ0Xo1J+UeKr4C3SXu3S7Ra4rBcEG/zAM05zliyHo+7c78bWZbg6V5jOAa+oBJcXsQCp+hIicKW9IcoPRFjoe9WeHvq92r0oZnW1+cDGl+MLedhM0+pI9hil postgres@prod_bd_102 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2a3HLxE1oldA8dGM3L83ESvslffQZ5uzsTE+Qwhem2EWQYKp4izSCRPqFqMGJk53aVGAOP4T+h2Hb43q5bGaRpGA giwwp4W6nbtq5835IftGGaDNaIDefibWJszAmrcsHSMpOXmF596Z5PoujPG4AXdwEU1XzoMj3O9sR+iE5IItxdw+EDiMOjL5LGHyMjjTC6l9zHsu83y93JaoUONpH4F /jpIgccZ0Xo1J+UeKr4C3SXu3S7Ra4rBcEG/zAM05zliyHo+7c78bWZbg6V5jOAa+oBJcXsQCp+hIicKW9IcoPRFjoe9WeHvq92r0oZnW1+cDGl+MLedhM0+pI9hil postgres@prod_bd_103

-- A partire do servidor "prod_bd_101", copie o diretório .ssh para os servidores prod_bd_102 e prod_bd_103 $ scp -rp ~/.ssh/ postgres@prod_bd_102:~/ $ scp -rp ~/.ssh/ postgres@prod_bd_103:~/

-- Em todos os servidores, é necessário alterar as permissões para os arquivos de senha do usuário postgres. $ ssh postgres@prod_bd_101 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys" $ ssh postgres@prod_bd_102 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys" $ ssh postgres@prod_bd_103 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

-- No servidor "prod_bd_101", tente conectar-se ao servidor prod_bd_102 e prod_bd_103, e verifique se a senha não é necessária $ ssh postgres@prod_bd_101 $ ssh postgres@prod_bd_102 $ ssh postgres@prod_bd_103

-- Agora entraremos no diretório /home/postgres do servidor "prod_bd_101" cd /home/postgres

-- Vamos baixar o pacote contendo a fonte do postgres-xl. wget https://sourceforge.net/projects/postgres-xl/files/Releases/Version_9.5r1/postgres-xl-9.5r1.4.tar.gz

-- copiar o arquivo que você acabou de baixar para todos os servidores do cluster scp postgres-xl-9.5r1.4.tar.gz postgres@prod_bd_102:~/ &&\ scp postgres-xl-9.5r1.4.tar.gz postgres@prod_bd_103:~/

-- Descompacte em cada respectivo servidor o arquivo postgres-xl-9.5r1.4.tar.gz ssh prod_bd_101 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/" &&\ ssh prod_bd_102 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/" &&\ ssh prod_bd_103 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"

-- Agora para cada servidor no cluster iremos configurar o código fonte e compilá-lo ssh prod_bd_101 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make" &&\ ssh prod_bd_102 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make" &&\ ssh prod_bd_103 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"

-- sair do usuário postgres usando o comando: exit

-- Instale o Postgres-XL como o usuário root ssh root@prod_bd_101 "cd /home/postgres/postgres-xl-9.5r1.4 && make install" &&\ ssh root@prod_bd_102 "cd /home/postgres/postgres-xl-9.5r1.4 && make install" &&\ ssh root@prod_bd_103 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"

Por padrão, o Postgres-XL é instalado no diretório /usr/local/pgsql/.

-- Instale o pgxc_ctl apenas no servidor "prod_bd_101" com o usuário "root" Entre no diretório do pgxc_ctl na home do usuário "postgres" # cd /home/postgres/postgres-xl-9.5r1.4/contrib/pgxc_ctl/ # make

-- Uma vez que o código fonte tenha sido compilado, o módulo deve ser instalado com o usuário root # make install

-- Adicione "/usr/local/pgsql/bin" no PATH para o usuário postgres # su postgres

-- Editar o arquivo /home/postgres/.bashrc, $ vi /home/postgres/.bashrc

-- Adicione a seguinte linha no final do arquivo: export PATH=/usr/local/pgsql/bin:$PATH

-- Copiar o arquivo modificado dentro de cada servidor $ scp -rp /home/postgres/.bashrc prod_bd_102:~/ $ scp -rp /home/postgres/.bashrc prod_bd_103:~/

-- Dentro de cada maquina fisica executar a atualização das mudanças do ambiente Obs. esses comandos não funcionam usando o ssh e portanto devem ser executados dentro todas as maquinas físicas do cluster. $ su postgres $ cd /home/postgres/ $ ..bashrc $ exit

-- Construímos o nosso cluster A configuração do cluster é facilitada pela ferramenta pgxc_ctl do nó 1. O nó salva seus arquivos de configuração por padrão em /home/postgres/pgxc_ctl e é feito principalmente através do arquivo /home/postgres/pgxc_ctl/pgxc_ctl.conf. As alterações podem ser feitas editando o arquivo manualmente ou usando o comando pgxc_ctl e, nesse caso, usaremos o último para gerar uma versão padrão do arquivo de configuração que personalizaremos posteriormente.

-- Verificando de estar com o usuário postgres devemos ver esse prompt [postgres@prod_bd_101 pgxc_ctl]$

ou no caso iremos usar o usuário postgres dando o comando no servidor prod_bd_101:

su postgres

-- Entramos no diretório /home/postgres/ cd /home/postgres/

-- Executamos o comando "pgxc_ctl" pela primeira vez. O resultado será um erro, mas será criado o diretório "pgxc_ctl" $ pgxc_ctl

-- Uma vez dentro do console de gerenciamento do cluster, digitaremos o comando prepare config empty

-- Este é o momento de personalizar a configuração do cluster vi /home/postgres/pgxc_ctl/pgxc_ctl.conf

-- Apenas modificamos esses três valores:

user and path

  • O administrador do cluster pgxcOwner=postgres
  • coordinator (Suponha-se que todos os coordenadores (master/slave) aceitam a mesma conexão ) coordPgHbaEntries=(192.168.22.0/24) datanodePgHbaEntries=(192.168.22.0/24)

    -- A próxima etapa é usar o pgxc_ctl para incluir os nós do cluster. Somente os parâmetros principais são especificados como, o nome do nó, seu endereço, as portas de conexão e o diretório de trabalho. O primeiro nó a ser adicionado será o nó de gerenciamento (GTM).

    -- Adicione o nó GTM (Global Transaction Manager) add gtm master gtm 192.168.22.101 20001 /home/postgres/pgxc/gtm

    -- Adicione o nó que serà o "Coordinador 1". add coordinator master coord1 192.168.22.102 20004 20010 /home/postgres/pgxc/coord_master_1 none none

    -- Adicione o nó que serà o "Coordinador 2". add coordinator master coord2 192.168.22.103 20005 20011 /home/postgres/pgxc/coord_master_2 none none

    -- Adicione o primeiro nó dos dados datanode1. add datanode master datanode1 192.168.22.102 20008 20012 /home/postgres/pgxc/dn1_master none none none

    -- Adicione o segundo nó dos dados datanode2. add datanode master datanode2 192.168.22.103 20009 20013 /home/postgres/pgxc/dn2_master none none none

    -- Verifique se todos os nós do cluster estão em execução monitor all

    -- Este deve ser o resultado mostrado na tela: Running: gtm master Running: coordinator master coord1 Running: coordinator master coord2 Running: datanode master datanode1 Running: datanode master datanode2

    -- No nó "prod_bd_101", execute o seguinte comando para criar um banco de dados de teste no cluster. pgxc_ctl Createdb test

    -- Sempre de dentro o console do PGXC, use a ferramenta psql para se conectar ao nó coordenador (prod_bd_102). psql -h prod_bd_102 -p 20004 test

    -- Crie uma tabela de hash que será distribuída entre os nós do cluster com base em um hash da coluna id. test=# create table hashed (id int, surname TEXT) DISTRIBUTE BY HASH(id); test=# insert into hashed VALUES (1, 'test');

    -- Execute o seguinte comando para obter as informações da tabela. Na última linha, observaremos uma informação que permite conhecer o nó no qual esta tabela está armazenada. test=# \d+ hashed

    -- Execute o seguinte comando para listar as instâncias desta tabela. test=# select * from hashed;

    -- Observe que a adição de outro nó de dados não redistribui automaticamente os dados já inseridos. Para verificar isso, nos conectaremos ao nó 2 usando o console do psql. PGXC psql -h prod_bd_102 -p 20004 test test=# \d+ hashed

    -- Para redistribuir os dados da tabela de hash para o novo nó, basta executar o seguinte comando. test=# ALTER TABLE hashed ADD NODE (datanode2);

    -- Verificamos que os dados na tabela de hash foram redistribuídos para o novo nó de dados. test=# \d+ hashed

    -- Caso precisar incluir um nó slave ao nó de dados master, no nó GTM ou prod_bd_101, execute o comando: add datanode slave datanode1 192.168.0.xxx 40101 40111 /home/postgres/pgxc/dn1_slave none /home/postgres/pgxc/dn1_archlog.1

    -- Vamos nos certificar de que nosso cluster funcione corretamente. PGXC monitor all

    -- Este deve ser o resultado mostrado na tela: Running: gtm master Running: coordinator master coord1 Running: coordinator master coord2 Running: datanode master datanode1 Running: datanode slave datanode1 Running: datanode master datanode2

    -- É importante saber que um nó slave funciona na replicação de dados de forma síncrona: test=# EXECUTE DIRECT ON(datanode1) 'SELECT client_hostname, state, sync_state FROM pg_stat_replication';

    -- Simulação de um failover Adicionamos alguns dados à tabela de hash para validar essa réplica. test=# INSERT INTO hashed SELECT generate_series(1001,1100), 'foo';

    -- Para localizar a distribuição de dados com base nos diferentes nós de dados, execute o seguinte 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;

    -- Para testar a tolerância a falhas e ver o interesse do nó de dados escravo, propomos parar o nó de dados 1 executando o seguinte comando. stop -m immediate datanode master datanode1

    -- A consulta no cluster agora é impossível porque faltam os dados (53 instâncias não estão mais disponíveis). Para verificar isso, execute a seguinte linha de 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;

    -- Como o Postgres-XL não suporta failover automático, ele deve ser explicitamente direcionado. Execute o seguinte comando. failover datanode datanode1

    -- Agora vamos verificar se a consulta anterior agora funciona corretamente. 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;

    -- O nó de dados slave agora substituiu o nó de dados mestre. Isso pode ser confirmado pelos resultados da consulta a seguir. test=# SELECT oid, * FROM pgxc_node;

    -- Deve-se observar que o nó de dados original 1 foi completamente removido do cluster. Não existe mais no arquivo de configuração pgxc_ctl.conf. Uma forma de reutilizá-lo, se disponível, é configurá-lo como um slave do novo nó de dados 1. Execute a próxima linha de comando. add datanode slave datanode1 192.168.22.104 20010 20014 /home/postgres/pgxc/dn1_master none /home/postgres/pgxc/dn1_archlo

    -- Para certificar-se de que o cluster está no estado desejado, execute a seguinte linha de comando monitor all

    -- Este deve ser o resultado mostrado na tela: Running: gtm master Running: coordinator master coord1 Running: datanode master datanode1 Running: datanode slave datanode1 Running: datanode master datanode2

    -- Para parar o Cluster executar o comando: stop all

    -- Nós vimos através deste tutorial a instalação do Postgres-XL, uma versão distribuída do banco de dados PostgreSQL, fazendo experiência em um cluster de teste composto de cinco nós.

    -- Esta versão oferece algumas características interessantes, como, por exemplo (distribuição de dados e consultas distribuídas em particular). No entanto, observamos algumas desvantagens devido, por exemplo, à recuperação de erros nos quais você precisa gerenciá-los manualmente.

    -- Em termos de perspectivas, seria interessante destacar no Postgres-XL:

    • robustez durante um aumento na carga horizontal;
    • funcionamento para um longo período;
    • a implementação de um balanceamento de carga;
    • tolerância de erro quando vários nós são perdidos.

    -- Referências

    https://www.postgres-xl.org/documentation/tutorial-createcluster.html https://www.postgres-xl.org/documentation/install-short.html https://www.postgres-xl.org/documentation/install-procedure.html https://sourceforge.net/projects/postgres-xl/files/Releases/Version_9.5r1/ https://www.postgres-xl.org/docu

 
Tags:

Posts Consigliati