OmniDB é uma ferramenta de gerenciamento de banco de dados gráfico de código aberto desenvolvida pela 2ndQuadrant, líder mundial em tecnologias e serviços PostgreSQL. OmniDB é uma ferramenta cliente universal baseada em navegador que pode gerenciar os principais mecanismos de banco de dados, como PostgreSQL, MariaDB, MySQL e Oracle. Outros mecanismos com suporte em breve incluem SQLite, Firebird, MS SQL Server e IBM DB2.
Como qualquer excelente software cliente de banco de dados, o OmniDB também capacita os usuários com alguns ótimos recursos. Isso inclui a capacidade de criar e personalizar painéis de monitoramento de desempenho do banco de dados. Nesta série de artigos de duas partes, aprenderemos como usar as unidades de monitoramento integradas do OmniDB – comumente conhecidas como “widgets” em termos de painel – para criar painéis de verificação de integridade de desempenho para um cluster de replicação PostgreSQL 12.
O ambiente de teste
Nosso ambiente de teste é um cluster PostgreSQL 12 de dois nós, executado em uma VPC da AWS na região us-east-1. A VPC abrange três zonas de disponibilidade e tem três sub-redes. Cada sub-rede está em uma zona de disponibilidade (AZ) separada. O nó principal e o nó de espera estão localizados em duas dessas sub-redes. Os nós são do tipo de instância t2.large do EC2 e executarão o PostgreSQL 12 de código aberto. O nó primário será replicado para o nó em espera.
Haverá também um “nó de monitoramento” executando a versão mais recente da ferramenta de gerenciamento de banco de dados OmniDB do 2ndQuadrant. Esse nó não fará parte do cluster PostgreSQL, mas será hospedado na terceira sub-rede da VPC, em outra AZ. O OmniDB poderá se conectar ao nó mestre e ao nó de espera e verificar seu desempenho. O nó OmniDB será uma instância t2.medium do EC2.
Todos os três nós estarão executando o Red Hat Enterprise Linux (RHEL) 8. A imagem abaixo mostra a arquitetura simplificada:
O Cenário de Teste
Assim que tivermos o cluster e o OmniDB configurados, registraremos os dois nós do PostgreSQL no OmniDB. Em seguida, nos familiarizaremos com algumas das unidades de monitoramento padrão no OmniDB e visualizaremos as métricas de desempenho de ambos os nós do cluster. Em seguida, executaremos um teste de carga no nó primário usando o pgbench. Idealmente, o teste de carga deve ser iniciado a partir de uma máquina separada, mas, neste caso, vamos executá-lo localmente. Veremos então como o painel de monitoramento do OmniDB mostra as alterações em vários contadores de desempenho à medida que a carga muda.
Configurando o ambiente
Etapa 1:Instalando um cluster de replicação do PostgreSQL 12
Para criar um cluster PostgreSQL de dois nós, estamos seguindo as etapas descritas em um blog do 2ndQuadrant publicado anteriormente. O leitor pode verificar este artigo para ver como instalamos um cluster de três nós com um nó testemunha usando outro produto 2ndQuadrant chamado repmgr . Para nossa configuração atual, estamos seguindo as mesmas etapas usando repmgr para criar um cluster de dois nós em vez de um de três nós. Além disso, o cluster de replicação não terá nenhum nó testemunha. Para simplificar, este artigo não mostra as etapas detalhadas de instalação e configuração.
Depois que nosso cluster estiver configurado, podemos confirmar que ele está funcionando consultando a visualização pg_stat_replication do nó primário:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsnFROM pg_stat_replication;
Etapa 2:Instalando e configurando um servidor OmniDB
O OmniDB é acessado usando uma URL, o que significa que, nos bastidores, ele executa um servidor web próprio. Existem dois tipos de OmniDB:
- Aplicativo OmniDB :normalmente é executado a partir de uma estação de trabalho e se comporta como um aplicativo de desktop normal. O OmniDB executa o servidor web em uma porta aleatória e não há necessidade de configuração adicional.
- Servidor OmniDB :serve para instalar o OmniDB em um servidor de rede para um modo multiusuário. No modo servidor, podemos especificar o número da porta para acessar a URL, criptografia SSL da URL, balanceamento de carga e proxy reverso, acesso de passagem SSH aos nós do banco de dados e criação de contas de usuário para acesso.
Para nosso cenário de teste, instalaremos um servidor OmniDB no nó OmniDB EC2. Primeiro, estamos baixando o pacote mais recente do site OmniDB:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Em seguida, iniciamos a instalação. Aqui, estamos instalando o OmniDB como usuário root, mas você pode usar qualquer outro usuário desde que tenha os direitos corretos:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmVerificando... ############################## #### [100%]Preparando... ################################# [100%]Atualizando / instalando... 1:omnidb-server-2.17.0-0 ################################# [ 100%]
Depois que o pacote estiver instalado, podemos iniciar o OmniDB no prompt de comando:
# servidor omnidb
Isso mostra o servidor iniciando:
Iniciando o websocket OmniDB...Verificando a disponibilidade da porta...Iniciando o servidor websocket na porta 25482 .Iniciando o servidor OmniDB...Verificando a disponibilidade da porta...Iniciando o servidor OmniDB 2.17.0 em 127.0.0.1:8000 .Iniciando a migração do banco de dados do usuário da versão 0.0.0 para a versão 2.17.0...O OmniDB migrou com sucesso o banco de dados do usuário da versão 0.0.0 para a versão 2.17.0Abra o OmniDB em seu navegador favoritoPressione Ctrl+C para sair
Podemos ver que o OmniDB escolheu uma porta de servidor web padrão de 8000 e um servidor websocket padrão na porta 25482.
Pressionamos Ctrl+C para parar o processo do servidor e navegar até o diretório inicial do usuário root. Podemos ver que há uma pasta oculta chamada .omnidb . Abaixo desta pasta, há um subdiretório chamado omnidb-server . Dentro do subdiretório omnidb-server, existem alguns arquivos:
# ls -la ~ …drwxr-xr-x. 3 root root 27 jun 13 02:49 .omnidb ……# ls -la ~/.omnidb …drwxr-xr-x. 2 root root 106 jun 13 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ …-rw-r--r--. 1 root root 131072 Jun 13 02:49 db.sqlite3-rw-r--r--. 1 root root 1209 Jun 13 02:49 omnidb.conf -rw-r--r--. 1 root root 116736 Jun 13 02:49 omnidb.db -r-r--r--. 1 root root 0 Jun 13 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 root root 579 Jun 13 02:49 omnidb.log
Depois que o processo do servidor é iniciado, o OmniDB inicializa esses arquivos. O banco de dados de metadados OmniDB é chamado omnidb.db . Este é um banco de dados SQLite e contém informações sobre conexões de banco de dados, usuários OmniDB e assim por diante. O omnidb.conf O arquivo contém opções de configuração para o servidor OmniDB. Se abrirmos este arquivo em um editor, ele se parecerá com o seguinte:
# Arquivo de configuração do servidor OmniDB[webserver]# Qual endereço o servidor web escuta, 0.0.0.0 escuta todos os endereços vinculados à máquinalistening_address =127.0.0.1 # Porta do servidor Web, se a porta estiver em uso, outra porta aleatória será selecionadalistening_port =8000 # Porta Websocket, se a porta estiver em uso, outra porta aleatória será selecionadawebsocket_port =25482 # Porta Websocket externa, use este parâmetro se o OmniDB não estiver diretamente visível pelo cliente# external_websocket_port =25482# Parâmetros de segurança# is_ssl =True requer os parâmetros ssl_certificate_file e ssl_key_file# Isso é altamente recomendado para proteger as informaçõesis_ssl =False ssl_certificate_file =/path/to/cert_file ssl_key_file =/path/to/key_file # Origens confiáveis, use este parâmetro se o OmniDB estiver configurado com SSL e estiver sendo acessado por outro domíniocsrf_trusted_origins =origin1,origin2,origin3# Caminho do URL para acessar o OmniDB, o padrão é vaziocaminho = [queryserver]# Número máximo de encadeamentos que podem ser usados por cada solicitação de pesquisa avançada de objetosthread_pool_max_workers =2 # Número de segundos entre cada solicitação de senha de prompt. Padrão:30 minutospwd_timeout_total =1800
O OmniDB executa dois processos de servidor. Um é um servidor web que exibe a interface do usuário, o outro é o servidor websocket. O servidor websocket é usado por vários recursos do aplicativo, como consulta, console e depuração.
A partir do arquivo de configuração, podemos ver que por padrão o servidor OmniDB aceita tráfego local (127.0.0.1) na porta 8000 do servidor web. Vamos alterar isso para TODOS os endereços IP. A menos que a máquina esteja atrás de um proxy reverso, é altamente recomendável usar a criptografia SSL para conexões HTTP com o servidor. Em nosso exemplo, porém, deixaremos o is_ssl parâmetro para "False" porque vamos derrubar esta máquina assim que nossos testes forem feitos. Também alteraremos a porta do servidor web para 8080 e manteremos a porta do servidor websocket em seu valor padrão de 25482.
Depois que as alterações forem feitas, o arquivo de configuração deve ficar assim:
[WebServer] auditivos_address =0.0.0.0Listening_port =8080WebSocket_port =25482is_sssl =Falsessl_Certificate_file =/PATH/TO/CERT_FILESSL_KEY_FILE =/PATH/TOKET_FILECSRF_TRUST_ENT_IGINS1S =ORIGHTEL1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMT1SEMTHET1SEMT1SEMTHET1STELTHET1STELT3>
Com as alterações feitas e salvas, executamos outro aplicativo chamado omnidb-config-server . Esta ferramenta pode ser usada para realizar algumas configurações extras como:
- Aspirando o banco de dados SQLite Banco de dados OmniDB
- Redefinir o banco de dados antigo e criar um novo
- Excluir arquivos temporários
- Crie um novo diretório inicial para o banco de dados e o arquivo de configuração
- Crie um superusuário para fazer login no OmniDB
Embora façamos login no OmniDB usando a conta de usuário admin que é criada por padrão, criaremos outro superusuário aqui. Isso pode ser útil se quisermos criar contas de DBA individuais no OmniDB. O trecho abaixo mostra isso:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Criando superusuário...Superusuário criado.
Com o superusuário criado, iniciamos o processo omnidb-server novamente:
# omnidb-serverIniciando o OmniDB websocket...Verificando a disponibilidade da porta...Iniciando o servidor websocket na porta 25482.Iniciando o servidor OmniDB...Verificando a disponibilidade da porta...Iniciando o servidor OmniDB 2.17.0 em 0.0.0.0:8080. A versão 2.17.0 do banco de dados do usuário já corresponde à versão do servidor.Abra o OmniDB em seu navegador favoritoPressione Ctrl+C para sair
Antes de acessar a interface OmniDB, também adicionamos a porta 8080 e a porta 25482 ao security group da instância do EC2:
Etapa 3:acessando a interface OmniDB
Navegar até o endereço público e o nó OmniDB agora mostra a tela de login:
Especificamos o nome de usuário padrão de “admin” e sua senha, “admin”. Isso nos permite fazer login na interface principal do OmniDB. A primeira tela é mostrada abaixo:
Em seguida, clicamos no ícone “Gerenciar usuários” no canto superior direito da tela:
E altere a senha padrão do usuário administrador:
Uma vez feito, clicamos no botão “Salvar dados” para atualizar a senha. Como você pode ver, também podemos criar novos usuários a partir desta tela.
No canto superior esquerdo da tela, clicamos no link “Conexões” e, na caixa de diálogo resultante, clicamos no botão “Nova conexão”:
Em seguida, especificamos os detalhes da conexão para o nó primário do PostgreSQL e clicamos no botão “Salvar dados”:
Uma vez que a conexão é salva, clicamos no ícone de conexão (marca verde) na coluna “Ações”.
Isso abre uma nova guia mostrando a conexão do banco de dados. Como mostrado aqui, estamos conectados ao nó primário do PostgreSQL aqui:
Seguimos o mesmo processo para registrar o nó de espera:
Etapa 4:Restaurando um banco de dados de amostra
Agora estamos restaurando um banco de dados de amostra na instância primária do PostgreSQL. Esse banco de dados é chamado de “DVDRental” e pode ser baixado gratuitamente no site Tutorial PostgreSQL. Descompactamos o arquivo baixado e extraímos os arquivos de origem em um subdiretório na pasta /tmp do nó primário:
[[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 raiz raiz 280 16 de junho 11:32 .drwxrwxrwt. 9 root root 257 Jun 16 11:31 ..-rw-------. 1 postgres postgres 57147 12 de maio de 2019 3055.dat-rw-------. 1 postgres postgres 8004 12 de maio de 2019 3057.dat-rw-------. 1 postgres postgres 483 12 de maio de 2019 3059.dat-rw-------. 1 postgres postgres 333094 12 de maio de 2019 3061.dat-rw-------. 1 postgres postgres 149469 12 de maio de 2019 3062.dat-rw-------. 1 postgres postgres 26321 12 de maio de 2019 3063.dat-rw-------. 1 postgres postgres 46786 12 de maio de 2019 3065.dat-rw-------. 1 postgres postgres 21762 12 de maio de 2019 3067.dat-rw-------. 1 postgres postgres 3596 12 de maio de 2019 3069.dat-rw-------. 1 postgres postgres 140422 12 de maio de 2019 3071.dat-rw-------. 1 postgres postgres 263 12 de maio de 2019 3073.dat-rw-------. 1 postgres postgres 718644 12 de maio de 2019 3075.dat-rw-------. 1 postgres postgres 1214420 12 de maio de 2019 3077.dat-rw-------. 1 postgres postgres 271 12 de maio de 2019 3079.dat-rw-------. 1 postgres postgres 57 12 de maio de 2019 3081.dat-rw-------. 1 postgres postgres 45872 12 de maio 2019 restore.sql-rw-------. 1 postgres postgres 55111 12 de maio de 2019 toc.dat
Em seguida, executamos os seguintes comandos de shell na instância primária do PostgreSQL (PG-Node1). Esses comandos fazem algumas alterações no arquivo restore.sql:
- Remova todas as ocorrências de “$$PATH$$/”. Isso garante que o script possa encontrar todos os arquivos de dados no mesmo diretório
- Alterar todas as ocorrências de “English_United States.1252” para “en_US.UTF-8”. Isso garante que não haja erros devido a uma localidade ausente quando o script for executado.
- Altere o comando “DROP DATBASE dvdrental” para “DROP DATBASE IF EXISTS dvdrental”, para que não apareça nenhum erro de banco de dados inválido.
# sed -i 's/$$PATH$$\//\/tmp\/dvdrental\//g' /tmp/dvdrental/restore.sql# sed -i 's/English_United States.1252/en_US .UTF-8/g' /tmp/dvdrental/restore.sql# sed -i 's/DROP DATABASE dvdrental;/DROP DATABASE SE EXISTE dvdrental;/g' /tmp/dvdrental/restore.sql
Em seguida, mudamos para o usuário postgres e executamos o seguinte comando no prompt do shell:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Isso restaura o banco de dados de amostra no nó primário. Se verificarmos no OmniDB, podemos ver que o banco de dados foi criado:
Conclusão
Agora temos um cluster PostgreSQL totalmente funcional e uma instância OmniDB em execução na AWS. O OmniDB pode se conectar a ambos os nós do cluster. Também restauramos um banco de dados no nó primário que está sendo replicado para o standby.
A configuração do ambiente está concluída. Na segunda parte deste artigo, começaremos a criar um painel de monitoramento de desempenho para a instância primária.
