One place for hosting & domains

      Gerenciado

      Como Migrar Dados do Redis para um Banco de Dados Gerenciado na DigitalOcean


      Introdução

      Existem vários métodos que você pode usar para migrar dados de uma instância Redis para outra, tais como a replicação ou o snapshotting. No entanto, as migrações podem ficar mais complicadas quando você está movendo dados para uma instância Redis gerenciada por um provedor de nuvem, uma vez que os bancos de dados gerenciados muitas vezes limitam o controle que você tem sobre a configuração dos mesmos.

      Este tutorial descreve um método que você pode usar para migrar dados para uma instância do Redis gerenciada pela DigitalOcean. O método usa o comando interno migrate do Redis para transmitir dados com segurança por um túnel TLS configurado com o stunnel. Este guia também abordará algumas outras estratégias de migração comumente usadas, e por que elas são problemáticas ao migrar para um Banco de dados gerenciado na DigitalOcean.

      Pré-requisitos

      Para concluir este tutorial, você precisará de:

      Nota: Para ajudar a manter as coisas claras, este guia fará referência à instância Redis hospedada no seu servidor Ubuntu como a “origem”. Da mesma forma, ele se referirá à instância gerenciada pela DigitalOcean como o “destino” ou o “Banco de Dados Gerenciado”.

      Coisas a Considerar ao Migrar Dados do Redis para um Banco de Dados Gerenciado

      Existem vários métodos que você pode empregar para migrar dados de uma instância Redis para outra. No entanto, algumas dessas abordagens apresentam problemas ao migrar dados para uma instância Redis gerenciada pela DigitalOcean.

      Por exemplo, você pode usar a replicação para transformar sua instância Redis de destino em uma cópia exata da origem. Para fazer isso, você se conectaria ao servidor Redis de destino e executaria o comando replicaof com a seguinte sintaxe:

      • replicaof ip_ou_hostname_da_origem porta_da_origem

      Isso fará com que a instância de destino replique todos os dados mantidos na origem sem destruir nenhum dado que estava armazenado anteriormente nela. Depois disso, você promoveria a réplica de volta a ser uma instância primária com o seguinte comando:

      No entanto, as instâncias Redis gerenciadas pela DigitalOcean são configuradas para se tornarem somente réplicas de leitura. Se você tiver clientes gravando dados no banco de dados de origem, você não poderá configurá-los para gravar na instância gerenciada, pois ela está replicando dados. Isso significa que você perderia todos os dados enviados pelos clientes após promover a instância gerenciada como uma réplica e antes de configurá-los para começar a gravar dados nela, tornando a replicação uma solução de migração ineficiente.

      Outro método para migrar dados do Redis é tirar um snapshot ou instantâneo dos dados mantidos em sua instância de origem com um dos comandos save ou bgsave do Redis. Ambos os comandos exportam o snapshot para um arquivo que termina em .rdb, que você então transfere para o servidor de destino. Depois disso, você reiniciaria o serviço Redis para que ele possa carregar os dados.

      No entanto, muitos provedores de bancos de dados gerenciados — incluindo a DigitalOcean — não permitem acessar o sistema de arquivos subjacente do servidor de banco de dados gerenciado. Isso significa que não há como fazer upload do arquivo de snapshot ou fazer as alterações necessárias no arquivo de configuração do banco de dados de destino para permitir que os Redis importe os dados.

      Como a configuração dos bancos de dados gerenciados da DigitalOcean limita a eficácia tanto da replicação e quanto do snapshotting como meio de migração de dados, este tutorial utilizará o comando migrate do Redis para mover dados da origem para o destino. O comando migrate é projetado para mover apenas uma chave de cada vez, mas vamos usar alguns truques de linha de comando para mover um banco de dados Redis inteiro com um único comando.

      Este passo opcional envolve o carregamento da instância Redis de origem com alguns dados de amostra para que você possa experimentar a migração de dados para o banco de dados Redis gerenciado. Se você já possui dados que deseja migrar para sua instância de destino, você pode avançar para o Passo 2.

      Para começar, execute o seguinte comando para acessar o seu servidor Redis:

      Se você configurou seu servidor Redis para exigir autenticação por senha, execute o comando auth seguido da sua senha Redis:

      Em seguida, execute os seguintes comandos. Isso criará um número de chaves contendo algumas strings, um hash, uma lista e um set:

      • mset string1 "Redis" string2 "is" string3 "fun!"
      • hmset hash1 field1 "Redis" field2 "is" field3 "fast!"
      • rpush list1 "Redis" "is" "feature-rich!"
      • sadd set1 "Redis" "is" "free!"

      Além disso, execute os seguintes comandos expire para fornecer um tempo limite para algumas dessas chaves. Isso as tornará voláteis, o que significa que o Redis as excluirá após o período especificado, 7500 segundos:

      • expire string2 7500
      • expire hash1 7500
      • expire set1 7500

      Com isso, você tem alguns dados de exemplo que podem ser exportados para sua instância Redis de destino. Você pode manter o prompt do redis-cli aberto por enquanto, pois executaremos mais alguns comandos a partir dele no próximo passo para fazer backup desses dados.

      Passo 2 — Fazendo Backup dos Seus Dados

      Anteriormente, discutimos o uso do comando bgsave do Redis para tirar uma snapshot de um banco de dados Redis e migrá-lo para outra instância. Embora não utilizemos o bgsave como meio de migrar os dados do Redis, vamos usá-lo aqui para fazer backup dos dados, caso encontremos um erro durante o processo de migração.

      Se você ainda não o tiver aberto, comece abrindo a interface de linha de comandos do Redis:

      Além disso, se você configurou o seu servidor Redis para exigir autenticação por senha, execute o comando auth seguido da sua senha Redis:

      Em seguida, execute o comando bgsave. Isso criará um snapshot do seu data set atual e o exportará para um arquivo de dump cujo nome termina em .rdb:

      Nota: Conforme mencionado na seção anterior Coisas a Considerar, você pode tirar um snapshot do seu banco de dados Redis com os comandos save ou bgsave. A razão pela qual usamos o comando bgsave aqui é que o comando save é executado de forma síncrona, o que significa que ele bloqueará quaisquer outros clientes conectados ao banco de dados. Por isto, a documentação do comando save recomenda que esse comando quase nunca seja executado em um ambiente de produção.

      Em vez disso, ela sugere o uso do comando bgsave, que executa de forma assíncrona. Isso fará com que o Redis faça um fork do banco de dados em dois processos: o processo pai continuará a servir os clientes enquanto o filho salva o banco de dados antes de sair:

      Observe que se os clientes adicionarem ou modificarem dados enquanto a operação bgsave estiver em execução ou após a conclusão, essas alterações não serão capturadas no snapshot.

      Depois disso, você pode fechar a conexão com sua instância Redis executando o comando exit:

      Se você precisar no futuro, você poderá encontrar este arquivo de dump no seu diretório de trabalho da instalação do Redis. Se você não tiver certeza de qual diretório é esse, pode verificar abrindo seu arquivo de configuração Redis com o seu editor de texto preferido. Aqui, usaremos o nano:

      • sudo nano /etc/redis/redis.conf

      Navegue até a linha que começa com dbfilename. Por padrão, ele se apresentará assim:

      /etc/redis/redis.conf

      . . .
      # The filename where to dump the DB
      dbfilename dump.rdb
      . . .
      

      Esta diretiva define o arquivo para o qual o Redis exportará snapshots. A próxima linha (após qualquer comentário) ficará assim:

      /etc/redis/redis.conf

      . . .
      dir /var/lib/redis
      . . .
      

      A diretiva dir define o diretório de trabalho do Redis onde os snapshots são armazenados. Por padrão, isso é definido como /var/lib/redis, como mostrado neste exemplo.

      Feche o arquivo redis.conf. Supondo que você não tenha alterado o arquivo, você pode fazer isso pressionando CTRL+X.

      Em seguida, liste o conteúdo do seu diretório de trabalho Redis para confirmar que ele está mantendo o arquivo de dump de dados exportado:

      Se o arquivo de dump foi exportado corretamente, você o verá na saída deste comando:

      Output

      dump.rdb

      Depois de confirmar que você fez backup dos seus dados com êxito, você pode iniciar o processo de migração para o seu Banco de Dados Gerenciado.

      Passo 3 — Migrando os Dados

      Lembre-se de que este guia usa o comando interno migrate do Redis para mover as chaves uma a uma do banco de dados de origem para o destino. No entanto, ao contrário dos passos anteriores deste tutorial, não executaremos este comando no prompt redis-cli. Em vez disso, vamos executá-lo diretamente no prompt bash do servidor. Isso nos permitirá usar alguns truques do bash para migrar todas as chaves no banco de dados de origem com um comando.

      Nota: Se você tiver clientes gravando dados na sua instância Redis de origem, agora seria um bom momento para configurá-los para também gravar dados no seu Banco de Dados Gerenciado. Dessa forma, você pode migrar os dados existentes da origem para o seu destino sem perder nenhuma gravação que ocorra após a migração.

      Além disso, esteja ciente de que este comando de migração não substituirá nenhuma chave existente no banco de dados de destino, a menos que uma das chaves existentes tenha o mesmo nome da chave que você está migrando.

      A migração ocorrerá após a execução do seguinte comando. Antes de executá-lo, porém, vamos dividi-lo parte por parte:

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 | while read key; do redis-cli -n banco_de_dados_de_origem -a senha_da_origem MIGRATE localhost 8000 "$key" banco_de_dados_de_destino 1000 COPY AUTH senha_do_redis_gerenciado; done

      Vamos analisar cada parte deste comando separadamente:

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 . . .

      A primeira parte do comando, redis-cli, abre uma conexão com o servidor Redis local. A flag -n especifica a qual dos bancos de dados lógicos do Redis se conectar. O Redis possui 16 bancos de dados prontos para uso (com o primeiro sendo numerado como 0, o segundo numerado como 1 e assim por diante), portanto, banco_de_dados_de_origem pode ser qualquer número entre 0 e 15. Se sua instância de origem mantém apenas dados no banco de dados padrão (numerado como 0), você não precisará incluir a flag -n ou especificar um número de banco de dados.

      A seguir, vem a flag -a e a senha da instância de origem, que juntos autenticam a conexão. Se sua instância de origem não exigir autenticação por senha, você não precisará incluir a flag -a.

      Em seguida, ele executa o comando scan do Redis, que itera sobre as chaves mantidas no data set e as retorna como uma lista. O scan requer ser seguido de um cursor — a iteração começa quando o cursor está definido como 0, e termina quando o servidor retorna um cursor 0. Portanto, seguimos o scan com um cursor 0 para iterar sobre todas as chaves do conjunto.

      • . . . | while read key; do . . .

      A próxima parte do comando começa com uma barra vertical (|). Nos sistemas tipo Unix, as barras verticais são conhecidas como pipes e são usadas para direcionar a saída de um processo para a entrada de outro.

      A seguir, é iniciado o loop while. No bash, assim como na maioria das linguagens de programação, um loop while é uma declaração de fluxo de controle que permite repetir um determinado processo, código ou comando, enquanto uma certa condição permanecer verdadeira.

      A condição neste caso é o subcomando read key, que lê a entrada que foi canalizada e a atribui à variável key. O ponto-e-vírgula (;) significa o final da declaração condicional do loop while, e o do a seguir precede a ação que será repetida enquanto a expressão while permanecer verdadeira. Toda vez que a instrução do for concluída, a instrução condicional lerá a próxima linha canalizada a partir do comando scan e atribuirá essa entrada à variável key.

      Essencialmente, esta seção diz “enquanto houver saída do comando scan para ser lida, execute a seguinte ação”.

      • . . . redis-cli -n banco_de_dados_de_origem -a senha_da_origem migrate localhost 8000 "$key" . . .

      Esta seção do comando é a que executa a migração real. Após outra chamada do redis-cli, ela especifica mais uma vez o número do banco de dados de origem com a flag -n e autentica com a flag -a. Você precisa incluí-las novamente, porque essa chamada redis-cli é distinta daquela no início do comando. Mais uma vez, porém, você não precisa incluir a flag -n ou o número do banco de dados se a instância Redis de origem mantém apenas dados no banco de dados padrão 0, e você não precisa incluir a flag -a se ela não requer autenticação por senha.

      A seguir, está o comando migrate. Sempre que você usar o comando migrate, deverá segui-lo com o nome do host ou endereço IP do banco de dados de destino e o número da porta. Aqui, seguimos a convenção estabelecida no tutorial de pré-requisito do stunnel e apontamos o comando migrate para localhost na porta 8000.

      $key é a variável definida na primeira parte do loop while e representa as chaves de cada linha da saída do comando scan.

      • . . . banco_de_dados_de_destino 1000 copy auth senha_do_redis_gerenciado; done

      Esta seção é uma continuação do comando migrate. Ela começa com banco_de_dados_de_destino, que representa o banco de dados lógico na instância de destino em que você deseja armazenar os dados. Novamente, este pode ser qualquer número entre 0 e 15.

      Em seguida está um número que representa um tempo limite. Esse tempo limite é a quantidade máxima de tempo de comunicação inativa entre as duas máquinas. Observe que este não é um limite de tempo para a operação, apenas que a operação deve sempre fazer algum nível de progresso dentro do tempo limite definido. Tanto o número do banco de dados quanto os argumentos de tempo limite são necessários para cada comando migrate.

      Após o tempo limite está a flag opcional copy. Por padrão, o migrate excluirá cada chave do banco de dados de origem depois de transferi-la para o destino; Ao incluir esta opção, você está instruindo o comando migrate a meramente copiar as chaves para que elas persistam na origem.

      Após o copy, aparece a flag auth, seguido da senha do seu Banco de Dados Redis Gerenciado. Isso não é necessário se você estiver migrando dados para uma instância que não requer autenticação, mas é necessário quando você estiver migrando dados para um banco gerenciado pela DigitalOcean.

      A seguir, outro ponto-e-vírgula, indicando o final da ação a ser executada enquanto a condição while for verdadeira. Finalmente, o comando fecha com done, indicando o fim do loop. O comando verifica a condição na instrução while e repete a ação na instrução do até que ela não seja mais verdadeira.

      Em conjunto, este comando executa os seguintes passos:

      • Examina um banco de dados na instância Redis de origem e retorna todas as chaves nela contidas
      • Passa cada linha da saída do comando scan para um loop while
      • Lê a primeira linha e atribui seu conteúdo à variável key
      • Migra qualquer chave no banco de dados de origem que corresponda à variável key para um banco de dados na instância Redis na outra extremidade do túnel TLS mantida em localhost na porta 8000
      • Volta e lê a próxima linha, e repete o processo até que não haja mais chaves para ler

      Agora que examinamos cada parte do comando de migração, você pode prosseguir e executá-lo.

      Se sua instância de origem tiver apenas dados no banco de dados 0 padrão, você não precisa incluir quaisquer das flags -n ou seus argumentos. Se, no entanto, você estiver migrando dados de qualquer banco de dados que não seja o 0 na sua instância de origem, você deve incluir as flags -n e alterar as duas ocorrências de banco_de_dados_de_origem para alinhar com o banco de dados que você deseja migrar.

      Se o seu banco de dados de origem exigir autenticação por senha, certifique-se de alterar senha_da_origem para a senha real da instância do Redis. Caso contrário, certifique-se de remover ambas as ocorrências de -a senha_da_origem do comando. Além disso, altere senha_do_redis_gerenciado para a senha do seu Banco de Dados Gerenciado e certifique-se de alterar banco_de_dados_de_destino para o número do banco de dados lógico na sua instância de destino em que você deseja gravar os dados:

      Nota: Se você não tiver a senha do seu banco de dados Redis gerenciado em mãos, poderá encontrá-la navegando primeiramente para o Painel de controle da DigitalOcean. A partir daí, clique em Databases no menu da barra lateral esquerda e depois clique no nome da instância Redis para a qual você deseja migrar os dados. Role para baixo até a seção Connection Details, onde você encontrará um campo chamado password. Clique no botão show para revelar a senha e copie e cole-a no comando de migração — substituindo senha_do_redis_gerenciado – para autenticar.

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0 | while read key; do redis-cli -n banco_de_dados_de_origem -a senha_da_origem MIGRATE localhost 8000 "$key" banco_de_dados_de_destino 1000 COPY AUTH senha_do_redis_gerenciado; done

      Você verá uma saída semelhante à seguinte:

      Output

      NOKEY OK OK OK OK OK OK

      Nota: Observe a primeira linha da saída do comando que lê NOKEY. Para entender o que isso significa, execute a primeira parte do comando de migração sozinho:

      • redis-cli -n banco_de_dados_de_origem -a senha_da_origem scan 0

      Se você migrou os dados de amostra adicionados no Passo 2, a saída deste comando será parecida com esta:

      Output

      1) "0" 2) 1) "hash1" 2) "string3" 3) "list1" 4) "string1" 5) "string2" 6) "set1"

      O valor "0" mantido na primeira linha não é uma chave mantida no seu banco de dados Redis de origem, mas um cursor retornado pelo comando scan. Como não há chaves no servidor denominadas “0”, não há nada lá para o comando migrate enviar à sua instância de destino e ele retorna NOKEY.

      No entanto, o comando não falha e sai. Em vez disso, ele continua lendo e migrando as chaves encontradas nas próximas linhas da saída do comando scan.

      Para testar se a migração foi bem-sucedida, conecte-se ao seu Banco de Dados Redis Gerenciado:

      • redis-cli -h localhost -p 8000 -a senha_do_redis_gerenciado

      Se você migrou dados para qualquer banco de dados lógico que não o padrão, conecte-se a esse banco de dados com o comando select:

      • select banco_de_dados_de_destino

      Execute um comando scan para ver quais chaves são mantidas lá:

      Se você concluiu o Passo 2 deste tutorial e adicionou os dados de exemplo ao seu banco de dados de origem, você verá resultados como este:

      Output

      1) "0" 2) 1) "set1" 2) "string2" 3) "hash1" 4) "list1" 5) "string3" 6) "string1"

      Por fim, execute um comando ttl em qualquer chave que você configurou para expirar para confirmar que ela ainda é volátil:

      Output

      (integer) 3944

      Esta saída mostra que, embora você tenha migrado a chave para o seu Banco de Dados Gerenciado, ela ainda está configurada para expirar com base no comando expireat que você executou anteriormente.

      Depois de confirmar que todas as chaves do seu banco de dados Redis de origem foram exportadas para o destino com êxito, você pode fechar sua conexão com o Banco de Dados Gerenciado. Se você tiver clientes gravando dados na instância Redis de origem e já os configurou para enviar suas gravações para o destino, nesse momento você pode configurá-los para parar de enviar dados para a origem.

      Conclusão

      Ao concluir este tutorial, você transferiu os dados do seu repositório de dados Redis autogerenciado para uma instância Redis gerenciada pela DigitalOcean. O processo descrito neste guia pode não ser o ideal em todos os casos. Por exemplo, você teria que executar o comando de migração várias vezes (uma vez para cada banco de dados lógico que contém dados) se sua instância de origem estiver usando bancos de dados diferentes do padrão. No entanto, quando comparado a outros métodos, como replicação ou snapshotting, este é um processo bastante direto que funciona bem com a configuração de um Banco de Dados Gerenciado pela DigitalOcean.

      Agora que você está usando um Banco de Dados Redis Gerenciado pela DigitalOcean para armazenar seus dados, você pode medir seu desempenho executando alguns testes de benchmarking. Além disso, se você é novo no trabalho com o Redis, você pode conferir nossa série Como Gerenciar um Banco de Dados Redis.



      Source link

      Como Instalar o WordPress com um Banco de Dados Gerenciado no Ubuntu 18.04


      Uma versão anterior deste tutorial foi escrita por Justin Ellingwood

      Introdução

      O WordPress é o CMS (sistema de gerenciamento de conteúdo) mais popular da Internet. É uma ótima opção para colocar um site em funcionamento rapidamente e, após a configuração inicial, quase toda a administração pode ser feita pela interface web.

      O WordPress foi projetado para buscar conteúdo – incluindo postagens, comentários, perfis de usuário e outros dados – de um banco de dados de back-end. À medida que um site cresce e deve satisfazer a cada vez mais tráfego, ele pode eventualmente crescer excessivamente o seu banco de dados inicial. Para resolver isso, pode-se ampliar o banco de dados migrando seus dados para uma máquina com mais RAM ou CPU, mas esse é um processo tedioso que corre o risco de perda ou corrupção de dados. É por isso que alguns desenvolvedores do WordPress optam por criar seus sites em bancos de dados gerenciados, que permitem aos usuários dimensionar seu banco de dados automaticamente com um risco muito menor de perda de dados.

      Neste guia, vamos focar na configuração de uma instância do WordPress com um banco de dados MySQL gerenciado e um servidor Ubuntu 18.04. Isso exigirá que você instale o PHP e o Apache para servir o conteúdo via web.

      Pré-requisitos

      Para concluir este tutorial, você precisará de:

      • Acesso a um servidor Ubuntu 18.04: Este servidor deve ter um usuário não-root com sudo habilitado e um firewall configurado. Você pode configurar isso seguindo nosso guia de Configuração Inicial de servidor com Ubuntu 18.04.
      • Um banco de dados MySQL gerenciado: Para provisionar um Banco de Dados MySQL Gerenciado na DigitalOcean, consulte nossa documentação de produto do Managed Databases. Observe que este guia se refere aos bancos de dados gerenciados da DigitalOcean nos exemplos, mas as instruções fornecidas aqui também devem geralmente funcionar para bancos de dados MySQL gerenciados de outros provedores de nuvem.
      • Uma pilha LAMP instalada em seu servidor: Além de um banco de dados, o WordPress requer um servidor web e o PHP para funcionar corretamente. A configuração de uma pilha LAMP completa (Linux, Apache, MySQL e PHP) atende a todos esses requisitos. Siga este guia para instalar e configurar estes softwares. Ao seguir este guia, certifique-se de configurar um virtual host para apontar para um nome de domínio que você possui. Além disso, certifique-se de pular o Passo 2, pois a instalação do mysql-server em sua máquina tornará sua instância de banco de dados gerenciada redundante.
      • Segurança TLS/SSL implementada para o seu site: Se você possui um nome de domínio, a maneira mais fácil de proteger seu site é com o Let’s Encrypt, que fornece certificados confiáveis e gratuitos. Siga nosso tutorial Let’s Encrypt guide for Apache para configurar isso. Observe que isso também exigirá que você obtenha um nome de domínio e configure registros DNS no seu servidor. Siga esta introdução ao DNS na DigitalOcean para detalhes sobre como configurar isso. Alternativamente, se você não tiver um nome de domínio, use um certificado autoassinado para o seu site.

      Quando terminar as etapas de configuração, efetue login no servidor como usuário não-root e continue logo abaixo.

      Passo 1 – Adicionando o Repositório de Software MySQL e Instalando o mysql-client

      Para configurar sua instância gerenciada do MySQL, você precisará instalar um cliente que permita acessar o banco de dados a partir do seu servidor. Este passo o guiará pelo processo de instalação do pacote mysql-client.

      Em muitos casos, você pode simplesmente instalar o mysql-client com o comando apt, mas se você estiver usando os repositórios padrão do Ubuntu, isso instalará a versão 5.7 do programa. Para acessar um banco de dados MySQL Gerenciado na DigitalOcean, você precisará instalar a versão 8.0 ou superior. Para fazer isso, você deve primeiro adicionar o repositório de software MySQL antes de instalar o pacote.

      Comece visitando a página MySQL APT Repository em seu navegador. Localize o botão Download no canto inferior direito e clique para avançcar para próxima página. Esta página solicitará que você efetue login ou inscreva-se em uma conta web da Oracle. Você pode pular isso e procurar o link que diz No thanks, just start my download. Clique com o botão direito do mouse no link e selecione Copy Link Address (esta opção pode aparecer de forma diferente, dependendo do seu navegador).

      Agora você está pronto para baixar o arquivo. No seu servidor, vá para um diretório no qual você pode gravar:

      Faça o download do arquivo usando curl, lembrando-se de colar o endereço que você acabou de copiar no lugar da parte destacada do comando a seguir. Você também precisa passar duas flags de linha de comando para o curl. -O instrui o curl para dar saída em um arquivo em vez da saída padrão. A flag L faz com que o curl siga redirecionamentos HTTP, o que é necessário neste caso, porque o endereço que você copiou realmente redireciona para outro local antes do download do arquivo:

      • curl -OL https://dev.mysql.com/get/mysql-apt-config_0.8.13-1_all.deb

      O arquivo agora deve ser baixado em seu diretório atual. Liste os arquivos para garantir:

      Você verá o nome do arquivo listado na saída:

      Output

      mysql-apt-config_0.8.13-1_all.deb . . .

      Agora você pode adicionar o repositório MySQL APT à lista de repositórios do seu sistema. O comando dpkg é usado para instalar, remover e inspecionar pacotes de software .deb. O comando a seguir inclui a flag -i, indicando que você deseja instalar a partir do arquivo especificado:

      • sudo dpkg -i mysql-apt-config*

      Durante a instalação, você verá uma tela de configuração onde poderá especificar qual versão do MySQL você prefere, além de uma opção para instalar repositórios para outras ferramentas relacionadas ao MySQL. Os padrões adicionarão as informações do repositório para a versão estável mais recente do MySQL e nada mais. É isso que queremos, então use a seta para baixo para navegar até a opção de menu Ok e pressione ENTER.

      Selecting mysql-apt-config configuration options

      Depois disso, o pacote terminará de adicionar o repositório. Atualize o cache de pacotes do apt para disponibilizar os novos pacotes de software:

      Em seguida, você pode limpar um pouco o sistema e excluir o arquivo baixado, pois não será necessário no futuro:

      Note: Se você precisar atualizar a configuração desses repositórios, basta executar o seguinte comando para selecionar suas novas opções:

      • sudo dpkg-reconfigure mysql-apt-config

      Após selecionar suas novas opções, execute o seguinte comando para atualizar o cache de pacotes:

      Agora que você adicionou os repositórios do MySQL, está pronto para instalar o software cliente do MySQL. Faça isso com o seguinte comando apt:

      • sudo apt install mysql-client

      Quando esse comando terminar, verifique o número da versão do software para garantir que você tenha a versão mais recente:

      Output

      mysql Ver 8.0.17-cluster for Linux on x86_64 (MySQL Community Server - GPL)

      Agora você pode se conectar ao seu banco de dados gerenciado e começar a prepará-lo para funcionar com o WordPress.

      Passo 2 – Criando um Banco de Dados MySQL e um Usuário para o WordPress

      O WordPress usa o MySQL para gerenciar e armazenar informações do site e de usuário. Supondo que você tenha concluído todos os tutoriais de pré-requisito, você já terá provisionado uma instância gerenciada do MySQL. Aqui, daremos o passo preparatório da criação de um banco de dados e um usuário para o WordPress usar.

      A maioria dos provedores de bancos de dados gerenciados fornece um uniform resource identifier (URI) usado para a conexão com a instância do banco de dados. Se você estiver usando um Banco de Dados Gerenciado na DigitalOcean, poderá encontrar as informações de conexão relevantes no seu Painel de Controle de Nuvem.

      Primeiro, clique em Databases no menu da barra lateral esquerda e selecione o banco de dados MySQL que você deseja usar para a instalação do WordPress. Role para baixo até a seção Connection Details e copie o link no campo host. Em seguida, cole este link no seguinte comando, substituindo uri_do_host pelas informações que você acabou de copiar. Da mesma forma, copie o número da porta no campo port – que será 25060 em um banco de dados gerenciado DigitalOcean – e substitua porta por esse número. Além disso, se esta é a primeira vez que você se conecta ao seu banco de dados gerenciado e você não criou seu próprio usuário administrativo do MySQL, copie o valor no campo username e cole-o no comando, substituindo usuário:

      • mysql -u usuário -p -h uri_do_host -P porta

      Este comando inclui a flag -p, que irá solicitar a senha do usuário do MySQL que você especificou. Para o usuário doadmin padrão do Banco de Dados Gerenciado da DigitalOcean, você pode encontrar isso clicando no link show na seção Connection Details para revelar a senha. Copie e cole-a no seu terminal quando solicitado.

      Nota: Se você não estiver usando um banco de dados gerenciado da DigitalOcean, suas opções de conexão podem ser diferentes. Se for esse o caso, consulte a documentação do seu provedor para obter instruções sobre como conectar aplicações de terceiros ao seu banco de dados.

      No prompt do MySQL, crie um novo banco de dados que o WordPress irá controlar. Você pode chama-lo como quiser, mas usaremos o nome wordpress neste guia para simplificar. Crie o banco de dados para o WordPress digitando:

      • CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

      Nota: Todo comando do MySQL deve terminar em ponto e vírgula (;). Verifique se isso está presente se você estiver enfrentando algum problema.

      Em seguida, crie uma nova conta de usuário MySQL que você usará exclusivamente para operar no novo banco de dados. Criar bancos de dados e contas de propósito único é uma boa ideia do ponto de vista de gerenciamento e segurança. Usaremos o nome wordpressuser neste guia, mas fique à vontade para alterá-lo, se desejar.

      Execute o seguinte comando, mas substitua ip_do_seu_servidor pelo endereço IP do seu servidor Ubuntu. Esteja ciente, no entanto, de que isso limitará o wordpressuser a poder se conectar somente a partir do seu servidor LAMP; se você planeja gerenciar o WordPress a partir do seu computador local, insira o endereço IP dessa máquina. Além disso, escolha uma senha forte para o usuário do banco de dados.

      Observe que este comando especifica que o wordpressuser usará o plugin mysql_native_password para se autenticar. No MySQL 8.0 e posterior, o plug-in de autenticação padrão é o caching_sha2_password, que geralmente é considerado mais seguro que o mysql_native_password. No momento da redação deste artigo, o PHP não suporta o caching_sha2_password, e é por isso que especificamos o mysql_native_password neste comando:

      • CREATE USER 'wordpressuser'@ip_do_seu_servidor IDENTIFIED WITH mysql_native_password BY 'senha';

      Nota: Se você não souber qual é o endereço IP público do seu servidor, existem várias maneiras de encontrá-lo. Geralmente, esse é o endereço que você usa para se conectar ao seu servidor através do SSH.

      Um método é utilizar o utilitário curl para entrar em contato com algo que está externo e perguntar como ele vê seu servidor. Por exemplo, você pode usar o curl para entrar em contato com uma ferramenta de verificação de IP como o ICanHazIP:

      • curl http://icanhazip.com

      Este comando retornará o endereço IP público do seu servidor em sua saída.

      Em seguida, conceda a esse usuário acesso ao banco de dados que você acabou de criar. Faça isso executando o seguinte comando:

      • GRANT ALL ON wordpress.* TO 'wordpressuser'@ip_do_seu_servidor;

      Agora você tem um banco de dados e uma conta de usuário, cada uma feita especificamente para o WordPress. Vá em frente e saia do MySQL digitando:

      Isso cuida da configuração do seu banco de dados MySQL gerenciado para funcionar com o WordPress. No próximo passo, você instalará algumas extensões PHP para obter mais funcionalidade do CMS.

      Passo 3 – Instalando Extensões PHP Adicionais

      Supondo que você seguiu o tutorial de pré-requisito da pilha LAMP, você terá instalado algumas extensões destinadas a fazer com que o PHP se comunique adequadamente com o MySQL. O WordPress e muitos de seus plugins utilizam extensões PHP adicionais para acrescentar funcionalidades adicionais.

      Para baixar e instalar algumas das extensões PHP mais populares para uso com o WordPress, execute o seguinte comando:

      • sudo apt install php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl php-zip

      Nota: Cada plugin do WordPress tem seu próprio conjunto de requisitos. Alguns podem exigir a instalação de pacotes PHP adicionais. Verifique a documentação do seu plug-in para ver quais extensões ele requer. Se estiverem disponíveis, elas podem ser instaladas com o apt como demonstrado acima.

      Você reiniciará o Apache para carregar essas novas extensões na próxima seção. No entanto, se você estiver retornando aqui para instalar plug-ins adicionais, poderá reiniciar o Apache agora, digitando:

      • sudo systemctl restart apache2

      Caso contrário, continue no Passo 4.

      Passo 4 – Ajustando a Configuração do Apache para Permitir Substituições e Reescritas via .htaccess

      Para que o Apache possa servir adequadamente sua instalação do WordPress, você deve fazer alguns pequenos ajustes na configuração dele.

      Se você seguiu os tutoriais de pré-requisito, já deve ter um arquivo de configuração para o seu site no diretório /etc/apache2/sites-available/. Usaremos /etc/apache2/sites-available/seu_domínio.conf como um exemplo aqui, mas você deve substituir o caminho para seu arquivo de configuração, onde apropriado.

      Além disso, usaremos /var/www/seu_domínio como o diretório raiz ou web root nessa instalação de exemplo do WordPress. Você deve usar o web root especificado em sua própria configuração.

      Nota: É possível que você esteja usando a configuração padrão 000-default.conf (com /var/www/html como seu web root). Isso é bom de usar se você estiver hospedando apenas um site neste servidor. Caso contrário, é melhor dividir a configuração necessária em partes lógicas, um arquivo por site.

      Atualmente, o uso de arquivos .htaccess está desativado. O WordPress e muitos plugins do WordPress usam esses arquivos extensivamente para ajustes do comportamento do servidor web no diretório .

      Abra o arquivo de configuração do Apache para o seu site:

      • sudo nano /etc/apache2/sites-available/seu_dominio.conf

      Para permitir arquivos .htaccess, você precisa definir a diretiva AllowOverride dentro de um bloco Directory apontando para seu document root. Adicione o seguinte bloco de texto dentro do bloco VirtualHost no seu arquivo de configuração, certificando-se de usar o diretório web root correto:

      /etc/apache2/sites-available/seu_domínio.conf

      <Directory /var/www/seu_dominio>
          AllowOverride All
      </Directory>
      

      Quando terminar, salve e feche o arquivo.

      Em seguida, ative o mod_rewrite para que você possa empregar o recurso de link permanente do WordPress:

      Antes de implementar as alterações que você acabou de fazer, verifique se não há erros de sintaxe no seu arquivo de configuração:

      • sudo apache2ctl configtest

      A saída deve ter uma mensagem parecida com esta:

      Output

      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK

      Se você deseja suprimir a linha superior, basta adicionar uma diretiva ServerName ao seu arquivo de configuração Apache principal (global) em /etc/apache2/apache2.conf. O ServerName pode ser o domínio ou endereço IP do seu servidor. No entanto, isso é apenas uma mensagem; isso não afeta a funcionalidade do seu site e, desde que a saída contenha Syntax OK, você estará pronto para continuar.

      Reinicie o Apache para efetivar as alterações:

      • sudo systemctl restart apache2

      Com isso, você está pronto para baixar e configurar o próprio WordPress.

      Passo 5 – Fazendo o Download do WordPress

      Agora que o software do seu servidor está configurado, você pode instalar e configurar o WordPress. Por motivos de segurança, é sempre recomendável obter a versão mais recente do WordPress no site dele.

      Primeiro, navegue para um diretório gravável. O /tmp funcionará para os propósitos deste passo:

      Em seguida, baixe a versão compactada digitando:

      • curl -O https://wordpress.org/latest.tar.gz

      Extraia o arquivo compactado para criar a estrutura de diretórios do WordPress:

      Você moverá esses arquivos para o seu document root momentaneamente. Antes de fazer isso, adicione um arquivo fictício .htaccess para que este fique disponível para uso posterior pelo WordPress.

      Crie o arquivo digitando:

      • touch /tmp/wordpress/.htaccess

      Além disso, copie o arquivo de configuração de exemplo para o nome do arquivo que o WordPress realmente lê:

      • cp /tmp/wordpress/wp-config-sample.php /tmp/wordpress/wp-config.php

      Crie um diretório upgrade, para que o WordPress não tenha problemas de permissão ao tentar fazer isso sozinho após uma atualização do software:

      • mkdir /tmp/wordpress/wp-content/upgrade

      Em seguida, copie todo o conteúdo do diretório para o document root. O comando a seguir usa um ponto no final do diretório de origem para indicar que tudo dentro do diretório deve ser copiado, incluindo arquivos ocultos (como o arquivo .htaccess que você acabou de criar):

      • sudo cp -a /tmp/wordpress/. /var/www/seu_domínio

      Isso cuida do download do WordPress em seu servidor. Neste ponto, no entanto, você ainda não poderá acessar a interface de configuração do WordPress no seu navegador. Para corrigir isso, você precisará fazer algumas alterações na configuração do WordPress do seu servidor.

      Passo 6 – Configurando o Diretório do WordPress

      Antes de passar pela configuração do WordPress usando a interface web, você precisa ajustar alguns itens no diretório do WordPress. Uma mudança importante na configuração envolve a configuração de permissões razoáveis e propriedade do arquivo.

      Comece dando a propriedade de todos os arquivos ao usuário e grupo www-data. Este é o usuário que o servidor web Apache executa como nos sistemas Debian e Ubuntu, e o Apache precisará ler e gravar arquivos do WordPress para servir o site e realizar atualizações automáticas.

      Atualize a propriedade do seu diretório web root com chown:

      • sudo chown -R www-data:www-data /var/www/seu_dominio

      Em seguida, execute os dois comandos find a seguir para definir as permissões corretas nos diretórios e arquivos do WordPress:

      • sudo find /var/www/seu_dominio/ -type d -exec chmod 750 {} ;
      • sudo find /var/www/seu_dominio/ -type f -exec chmod 640 {} ;

      Essas devem ser permissões razoáveis definidas para começar. Esteja ciente, no entanto, de que alguns plug-ins e procedimentos podem exigir atualizações adicionais.

      Agora, você precisa fazer algumas alterações no arquivo de configuração principal do WordPress.

      Quando você abre o arquivo, a primeira ordem do dia será substituir algumas chaves secretas para fornecer segurança à sua instalação. O WordPress fornece um gerador seguro para esses valores, para que você não precise criar bons valores por conta própria. Eles são usados apenas internamente, portanto, não prejudicará a usabilidade ter valores complexos e seguros aqui.

      Para obter valores seguros do gerador de chave secreta do WordPress, execute o seguinte comando:

      • curl -s https://api.wordpress.org/secret-key/1.1/salt/

      Você receberá de volta valores únicos parecidos com este:

      Atenção! É importante que você solicite valores exclusivos a cada vez. NÃO copie os valores mostrados aqui!

      Output

      define('AUTH_KEY', '1jl/vqfs<XhdXoAPz9 DO NOT COPY THESE VALUES c_j{iwqD^<+c9.k<J@4H'); define('SECURE_AUTH_KEY', 'E2N-h2]Dcvp+aS/p7X DO NOT COPY THESE VALUES {Ka(f;rv?Pxf})CgLi-3'); define('LOGGED_IN_KEY', 'W(50,{W^,OPB%PB<JF DO NOT COPY THESE VALUES 2;y&,2m%3]R6DUth[;88'); define('NONCE_KEY', 'll,4UC)7ua+8<!4VM+ DO NOT COPY THESE VALUES #`DXF+[$atzM7 o^-C7g'); define('AUTH_SALT', 'koMrurzOA+|L_lG}kf DO NOT COPY THESE VALUES 07VC*Lj*lD&?3w!BT#-'); define('SECURE_AUTH_SALT', 'p32*p,]z%LZ+pAu:VY DO NOT COPY THESE VALUES C-?y+K0DK_+F|0h{!_xY'); define('LOGGED_IN_SALT', 'i^/G2W7!-1H2OQ+t$3 DO NOT COPY THESE VALUES t6**bRVFSD[Hi])-qS`|'); define('NONCE_SALT', 'Q6]U:K?j4L%Z]}h^q7 DO NOT COPY THESE VALUES 1% ^qUswWgn+6&xqHN&%');

      Estas são linhas de configuração que você pode colar diretamente no seu arquivo de configuração para definir chaves seguras. Copie a saída que você recebeu agora.

      Em seguida, abra o arquivo de configuração do WordPress:

      • sudo nano /var/www/seu_domínio/wp-config.php

      Encontre a seção que contém os valores fictícios para essas configurações. Vai parecer com algo assim:

      /var/www/your_domain/wp-config.php

      . . .
      
      define('AUTH_KEY',         'put your unique phrase here');
      define('SECURE_AUTH_KEY',  'put your unique phrase here');
      define('LOGGED_IN_KEY',    'put your unique phrase here');
      define('NONCE_KEY',        'put your unique phrase here');
      define('AUTH_SALT',        'put your unique phrase here');
      define('SECURE_AUTH_SALT', 'put your unique phrase here');
      define('LOGGED_IN_SALT',   'put your unique phrase here');
      define('NONCE_SALT',       'put your unique phrase here');
      
      . . .
      

      Exclua essas linhas e cole os valores que você copiou da linha de comando:

      /var/www/your_domain/wp-config.php

      . . .
      
      define('AUTH_KEY',         'VALUES COPIED FROM THE COMMAND LINE');
      define('SECURE_AUTH_KEY',  'VALUES COPIED FROM THE COMMAND LINE');
      define('LOGGED_IN_KEY',    'VALUES COPIED FROM THE COMMAND LINE');
      define('NONCE_KEY',        'VALUES COPIED FROM THE COMMAND LINE');
      define('AUTH_SALT',        'VALUES COPIED FROM THE COMMAND LINE');
      define('SECURE_AUTH_SALT', 'VALUES COPIED FROM THE COMMAND LINE');
      define('LOGGED_IN_SALT',   'VALUES COPIED FROM THE COMMAND LINE');
      define('NONCE_SALT',       'VALUES COPIED FROM THE COMMAND LINE');
      
      . . .
      

      Em seguida, você precisa modificar algumas das configurações de conexão com o banco de dados no início do arquivo. Primeiro, atualize os campos 'DB_NAME', 'DB_USER', e 'DB_PASSWORD' para apontar para o nome do banco de dados, o usuário do banco de dados e a senha associada que você configurou no MySQL:

      /var/www/your_domain/wp-config.php

      . . .
      /** The name of the database for WordPress */
      define('DB_NAME', 'wordpress');
      
      /** MySQL database username */
      define('DB_USER', 'wordpressuser');
      
      /** MySQL database password */
      define('DB_PASSWORD', 'password');
      
      . . .
      

      Você também precisará substituir o localhost no campo 'DB_HOST' pelo host do seu banco de dados gerenciado. Além disso, anexe dois pontos (:) e o número da porta do seu banco de dados ao host:

      /var/www/wordpress/wp-config.php

      . . .
      
      /** MySQL hostname */
      define( 'DB_HOST', 'managed_database_host:managed_database_port' );
      
      . . .
      

      A última alteração que você precisa fazer é definir o método que o WordPress usará para gravar no sistema de arquivos. Como você já deu permissão ao servidor web para gravar onde ele precisa, você pode definir explicitamente o método do sistema de arquivos para direct port. Se você não definir isso com as configurações atuais, o WordPress poderá solicitar credenciais de FTP quando você executar determinadas ações.

      Essa configuração pode ser adicionada abaixo das configurações de conexão com o banco de dados ou em qualquer outro local do arquivo:

      /var/www/your_domain/wp-config.php

      . . .
      
      define('FS_METHOD', 'direct');
      . . .
      

      Salve e feche o arquivo ao terminar.

      Depois de fazer essas alterações, você está pronto para concluir o processo de instalação do WordPress em seu navegador. No entanto, há mais uma etapa que recomendamos que você complete para adicionar uma camada extra de segurança à sua configuração.

      Neste ponto, sua instalação do WordPress está se comunicando com o banco de dados MySQL gerenciado. No entanto, não há garantia de que as transferências de dados entre as duas máquinas sejam seguras. Neste passo, configuraremos o WordPress para se comunicar com sua instância do MySQL por meio de uma conexão TLS/SSL para garantir comunicações seguras entre as duas máquinas.

      Para fazer isso, você precisará do certificado da CA do seu banco de dados gerenciado. Para um banco de dados gerenciado na DigitalOcean, você pode encontrá-lo navegando novamente até a guia Databases no Control Panel. Clique no seu banco de dados e encontre a seção Connection Details. Haverá um botão que diz Download the CA certificate. Clique neste botão para baixar o certificado na sua máquina local.

      Em seguida, transfira esse arquivo para o seu servidor WordPress. Se sua máquina local estiver executando Linux ou macOS, você pode usar uma ferramenta como o scp:

      • scp /caminho/para/o/arquivo/ca-certificate.crt sammy@ip_do_seu_servidor:/tmp

      Se sua máquina local estiver executando o Windows, você poderá usar uma ferramenta alternativa como o WinSCP.

      Quando o certificado da CA estiver no seu servidor, mova-o para o diretório /user/local/share/ca-certificates/, o repositório de certificados confiáveis do Ubuntu:

      • sudo mv /tmp/ca-certificate.crt /usr/local/share/ca-certificates/

      Depois disso, execute o comando update-ca-certificates. Este programa procura certificados dentro de /usr/local/share/ca-certificates, adiciona novos no diretório /etc/ssl/certs/ e gera uma lista de certificados SSL confiáveis com base em seu conteúdo:

      • sudo update-ca-certificates

      Em seguida, reabra seu arquivo wp-config.php:

      • nano /var/www/seu_domínio/wp-config.php

      Em algum lugar do arquivo, adicione a seguinte linha:

      /var/www/seu_domínio/wp-config.php

      . . .
      define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
      . . .
      

      Salve e feche o arquivo.

      Depois disso, o WordPress se comunicará com segurança com seu banco de dados MySQL gerenciado.

      Passo 8 – Concluindo a Instalação pela Interface Web

      Agora que a configuração do servidor está concluída, você pode concluir a instalação através da interface web do WordPress.

      No seu navegador, navegue até o nome de domínio ou endereço IP público do seu servidor:

      https://domínio_ou_ip_do_servidor
      

      Supondo que não haja erros nas configurações do seu WordPress ou do Apache, você verá a página inicial da seleção de idiomas do WordPress. Selecione o idioma que você gostaria de usar:

      WordPress language selection

      Depois de selecionar seu idioma, você verá a página principal de configuração.

      Escolha um nome para o seu site WordPress e escolha um nome de usuário (é recomendável não escolher algo como “admin” por motivos de segurança). Uma senha forte é gerada automaticamente. Salve esta senha ou insira uma senha alternativa forte.

      Digite seu endereço de email e selecione se deseja desencorajar os mecanismos de pesquisa de fazer indexação do seu site:

      WordPress setup installation

      Ao clicar adiante, você será direcionado para uma página que solicita que você faça login:

      WordPress login prompt

      Após o login, você será direcionado para o painel de administração do WordPress:

      WordPress login prompt

      A partir daqui, você pode começar a personalizar seu novo site WordPress e começar a publicar conteúdo. Se for a primeira vez que você usa o WordPress, recomendamos que você explore um pouco a interface para se familiarizar com o seu novo CMS.

      Conclusão

      Ao concluir este guia, você terá o WordPress instalado e pronto para uso em seu servidor. Além disso, sua instalação do WordPress busca dinamicamente postagens, páginas e outros conteúdos do seu banco de dados MySQL gerenciado.

      Algumas das próximas etapas comuns são escolher a configuração de links permanentes ou permalinks para suas postagens. Essa configuração pode ser encontrada em Configurações > Permalinks. Você também pode selecionar um novo tema em Aparência > Temas. Depois de começar a carregar algum conteúdo no seu site, você também pode configurar uma CDN para acelerar a entrega de elementos do seu site.



      Source link

      Como Analisar as Estatísticas do Banco de Dados PostgreSQL Gerenciado Usando o Elastic Stack no Ubuntu 18.04


      O autor escolheu o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O monitoramento de banco de dados é o processo contínuo de rastrear sistematicamente várias métricas que mostram como o banco de dados está se comportando. Ao observar os dados de desempenho, você pode obter informações valiosas e identificar possíveis gargalos, além de encontrar maneiras adicionais de melhorar o desempenho do banco de dados. Esses sistemas geralmente implementam alertas que notificam os administradores quando as coisas dão errado. As estatísticas coletadas podem ser usadas não apenas para melhorar a configuração e o fluxo de trabalho do banco de dados, mas também para os aplicativos clientes.

      Os benefícios da utilização do Elastic Stack (ELK stack) para monitorar seu banco de dados gerenciado, é seu excelente suporte para pesquisa e a capacidade de ingerir novos dados muito rapidamente. Ele não se destaca na atualização dos dados, mas esse trade-off é aceitável para fins de monitoramento e logs, onde dados passados quase nunca são alterados. O Elasticsearch oferece meios poderosos de consultar os dados, que você pode usar através do Kibana para entender melhor como o banco de dados se sai em diferentes períodos de tempo. Isso permitirá que você correlacione a carga do banco de dados com eventos da vida real para obter informações sobre como o banco de dados está sendo usado.

      Neste tutorial, você importará métricas de banco de dados geradas pelo coletor de estatísticas do PostgreSQL no Elasticsearch via Logstash. Isso implica em configurar o Logstash para extrair dados do banco de dados usando o conector JDBC do PostgreSQL para enviá-los ao Elasticsearch para indexação imediatamente após. Os dados importados podem ser analisados e visualizados posteriormente no Kibana. Então, se seu banco de dados for novo, você usará o pgbench, uma ferramenta de benchmarking do PostgreSQL, para criar visualizações mais interessantes. No final, você terá um sistema automatizado buscando as estatísticas do PostgreSQL para análise posterior.

      Pré-requisitos

      Passo 1 — Configurando o Logstash e o Driver JDBC para PostgreSQL

      Nesta seção, você instalará o Logstash e fará o download do driver JDBC para PostgreSQL para que o Logstash possa se conectar ao seu banco de dados gerenciado.

      Comece instalando o Logstash com o seguinte comando:

      • sudo apt install logstash -y

      Depois que o Logstash estiver instalado, habilite o serviço para iniciar automaticamente na inicialização:

      • sudo systemctl enable logstash

      O Logstash é escrito em Java, portanto, para conectar-se ao PostgreSQL, é necessário que a biblioteca JDBC (Java Database Connectivity) do PostgreSQL esteja disponível no sistema em que está sendo executado. Por causa de uma limitação interna, o Logstash carregará adequadamente a biblioteca apenas se for encontrada no diretório /usr/share/logstash/logstash-core/lib/jars, onde armazena bibliotecas de terceiros que ele utiliza.

      Vá para a página de download da biblioteca JDBC e copie o link para a versão mais recente. Em seguida, faça o download usando curl executando o seguinte comando:

      • sudo curl https://jdbc.postgresql.org/download/postgresql-42.2.6.jar -o /usr/share/logstash/logstash-core/lib/jars/postgresql-jdbc.jar

      No momento da escrita deste tutorial, a versão mais recente da biblioteca era a 42.2.6, com o Java 8 como a versão runtime suportada. Certifique-se de baixar a versão mais recente; emparelhando-a com a versão Java correta que tanto o JDBC quanto o Logstash suportam.

      O Logstash armazena seus arquivos de configuração em /etc/logstash/conf.d e armazena a si próprio em /usr/share/logstash/bin. Antes de criar uma configuração que coletará estatísticas do seu banco de dados, será necessário ativar o plug-in JDBC no Logstash executando o seguinte comando:

      • sudo /usr/share/logstash/bin/logstash-plugin install logstash-input-jdbc

      Você instalou o Logstash usando o apt e baixou a biblioteca JDBC do PostgreSQL para que o Logstash possa usá-la para conectar-se ao seu banco de dados gerenciado. Na próximo passo, você configurará o Logstash para coletar dados estatísticos dele.

      Passo 2 — Configurando o Logstash Para Coletar Estatísticas

      Nesta seção, você configurará o Logstash para coletar métricas do seu banco de dados PostgreSQL gerenciado.

      Você configurará o Logstash para monitorar três bancos de dados de sistema no PostgreSQL, a saber:

      • pg_stat_database: fornece estatísticas sobre cada banco de dados, incluindo seu nome, número de conexões, transações, rollbacks, linhas retornadas ao consultar o banco de dados, deadlocks e assim por diante. Possui um campo stats_reset, que especifica quando as estatísticas foram zeradas pela última vez.
      • pg_stat_user_tables: fornece estatísticas sobre cada tabela criada pelo usuário, como o número de linhas inseridas, excluídas e atualizadas.
      • pg_stat_user_indexes: coleta dados sobre todos os índices em tabelas criadas pelo usuário, como o número de vezes que um índice específico foi consultado.

      Você armazenará a configuração para indexar as estatísticas do PostgreSQL no Elasticsearch em um arquivo chamado postgresql.conf no diretório /etc/logstash/conf.d, onde o Logstash armazena arquivos de configuração. Quando iniciado como um serviço, ele será executado automaticamente em segundo plano.

      Crie o postgresql.conf usando seu editor de textos favorito (por exemplo, o nano):

      • sudo nano /etc/logstash/conf.d/postgresql.conf

      Adicione as seguintes linhas:

      /etc/logstash/conf.d/postgresql.conf

      input {
              # pg_stat_database
              jdbc {
                      jdbc_driver_library => ""
                      jdbc_driver_class => "org.postgresql.Driver"
                      jdbc_connection_string => "jdbc:postgresql://host:port/defaultdb"
                      jdbc_user => "username"
                      jdbc_password => "password"
                      statement => "SELECT * FROM pg_stat_database"
                      schedule => "* * * * *"
                      type => "pg_stat_database"
              }
      
              # pg_stat_user_tables
              jdbc {
                      jdbc_driver_library => ""
                      jdbc_driver_class => "org.postgresql.Driver"
                      jdbc_connection_string => "jdbc:postgresql://host:port/defaultdb"
                      jdbc_user => "username"
                      jdbc_password => "password"
                      statement => "SELECT * FROM pg_stat_user_tables"
                      schedule => "* * * * *"
                      type => "pg_stat_user_tables"
              }
      
              # pg_stat_user_indexes
              jdbc {
                      jdbc_driver_library => ""
                      jdbc_driver_class => "org.postgresql.Driver"
                      jdbc_connection_string => "jdbc:postgresql://host:port/defaultdb"
                      jdbc_user => "username"
                      jdbc_password => "password"
                      statement => "SELECT * FROM pg_stat_user_indexes"
                      schedule => "* * * * *"
                      type => "pg_stat_user_indexes"
              }
      }
      
      output {
              elasticsearch {
                      hosts => "http://localhost:9200"
                      index => "%{type}"
              }
      }
      

      Lembre-se de substituir host pelo seu endereço de host, port pela porta à qual você pode se conectar ao seu banco de dados, username pelo nome de usuário do banco de dados e password pela sua senha. Todos esses valores podem ser encontrados no Painel de Controle do seu banco de dados gerenciado.

      Nesta configuração, você define três entradas JDBC e uma saída Elasticsearch. As três entradas extraem dados dos bancos de dados pg_stat_database, pg_stat_user_tables e pg_stat_user_indexes, respectivamente. Todos eles definem o parâmetro jdbc_driver_library como uma string vazia, porque a biblioteca JDBC do PostgreSQL está em uma pasta que o Logstash carrega automaticamente.

      Em seguida, eles definem o jdbc_driver_class, cujo valor é específico da biblioteca JDBC, e fornecem uma jdbc_connection_string, que detalha como se conectar ao banco de dados. A parte jdbc: significa que é uma conexão JDBC, enquanto postgres:// indica que o banco de dados de destino é o PostgreSQL. Em seguida, vem o host e a porta do banco de dados e, após a barra, você também especifica um banco de dados ao qual se conectar; isso ocorre porque o PostgreSQL exige que você esteja conectado a um banco de dados para poder emitir quaisquer consultas. Aqui, ele está definido como o banco de dados padrão que sempre existe e não pode ser excluído, apropriadamente denominado de defaultdb.

      Em seguida, eles definem um nome de usuário e a senha do usuário através do qual o banco de dados será acessado. O parâmetro statement contém uma consulta SQL que deve retornar os dados que você deseja processar — nessa configuração, ele seleciona todas as linhas do banco de dados apropriado.

      O parâmetro schedule aceita uma string na sintaxe do cron que define quando o Logstash deve executar esta entrada; omiti-lo completamente fará com que o Logstash a execute apenas uma vez. Especificando * * * * *, como você fez aqui, dirá ao Logstash para executá-la a cada minuto. Você pode especificar sua própria string do cron se desejar coletar dados em diferentes intervalos.

      Há apenas uma saída, que aceita dados de três entradas. Todas elas enviam dados para o Elasticsearch, que está sendo executado localmente e pode ser acessado em http://localhost:9200. O parâmetro index define para qual índice do Elasticsearch ele enviará os dados e seu valor é passado no campo type da entrada.

      Quando você terminar de editar, salve e feche o arquivo.

      Você configurou o Logstash para reunir dados de várias tabelas estatísticas do PostgreSQL e enviá-los ao Elasticsearch para armazenamento e indexação. Em seguida, você executará o Logstash para testar a configuração.

      Passo 3 — Testando a Configuração do Logstash

      Nesta seção, você testará a configuração executando o Logstash para verificar se ele extrairá os dados corretamente. Em seguida, você executará essa configuração em segundo plano, configurando-a como um pipeline do Logstash.

      O Logstash suporta a execução de uma configuração específica, passando seu caminho de arquivo para o parâmetro -f. Execute o seguinte comando para testar sua nova configuração da último passo:

      • sudo /usr/share/logstash/bin/logstash -f /etc/logstash/conf.d/postgresql.conf

      Pode levar algum tempo até que ele mostre qualquer saída, que será semelhante a esta:

      Output

      Thread.exclusive is deprecated, use Thread::Mutex WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults Could not find log4j2 configuration at path /usr/share/logstash/config/log4j2.properties. Using default config which logs errors to the console [WARN ] 2019-08-02 18:29:15.123 [LogStash::Runner] multilocal - Ignoring the 'pipelines.yml' file because modules or command line options are specified [INFO ] 2019-08-02 18:29:15.154 [LogStash::Runner] runner - Starting Logstash {"logstash.version"=>"7.3.0"} [INFO ] 2019-08-02 18:29:18.209 [Converge PipelineAction::Create<main>] Reflections - Reflections took 77 ms to scan 1 urls, producing 19 keys and 39 values [INFO ] 2019-08-02 18:29:20.195 [[main]-pipeline-manager] elasticsearch - Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[http://localhost:9200/]}} [WARN ] 2019-08-02 18:29:20.667 [[main]-pipeline-manager] elasticsearch - Restored connection to ES instance {:url=>"http://localhost:9200/"} [INFO ] 2019-08-02 18:29:21.221 [[main]-pipeline-manager] elasticsearch - ES Output version determined {:es_version=>7} [WARN ] 2019-08-02 18:29:21.230 [[main]-pipeline-manager] elasticsearch - Detected a 6.x and above cluster: the `type` event field won't be used to determine the document _type {:es_version=>7} [INFO ] 2019-08-02 18:29:21.274 [[main]-pipeline-manager] elasticsearch - New Elasticsearch output {:class=>"LogStash::Outputs::ElasticSearch", :hosts=>["http://localhost:9200"]} [INFO ] 2019-08-02 18:29:21.337 [[main]-pipeline-manager] elasticsearch - Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[http://localhost:9200/]}} [WARN ] 2019-08-02 18:29:21.369 [[main]-pipeline-manager] elasticsearch - Restored connection to ES instance {:url=>"http://localhost:9200/"} [INFO ] 2019-08-02 18:29:21.386 [[main]-pipeline-manager] elasticsearch - ES Output version determined {:es_version=>7} [WARN ] 2019-08-02 18:29:21.386 [[main]-pipeline-manager] elasticsearch - Detected a 6.x and above cluster: the `type` event field won't be used to determine the document _type {:es_version=>7} [INFO ] 2019-08-02 18:29:21.409 [[main]-pipeline-manager] elasticsearch - New Elasticsearch output {:class=>"LogStash::Outputs::ElasticSearch", :hosts=>["http://localhost:9200"]} [INFO ] 2019-08-02 18:29:21.430 [[main]-pipeline-manager] elasticsearch - Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[http://localhost:9200/]}} [WARN ] 2019-08-02 18:29:21.444 [[main]-pipeline-manager] elasticsearch - Restored connection to ES instance {:url=>"http://localhost:9200/"} [INFO ] 2019-08-02 18:29:21.465 [[main]-pipeline-manager] elasticsearch - ES Output version determined {:es_version=>7} [WARN ] 2019-08-02 18:29:21.466 [[main]-pipeline-manager] elasticsearch - Detected a 6.x and above cluster: the `type` event field won't be used to determine the document _type {:es_version=>7} [INFO ] 2019-08-02 18:29:21.468 [Ruby-0-Thread-7: :1] elasticsearch - Using default mapping template [INFO ] 2019-08-02 18:29:21.538 [Ruby-0-Thread-5: :1] elasticsearch - Using default mapping template [INFO ] 2019-08-02 18:29:21.545 [[main]-pipeline-manager] elasticsearch - New Elasticsearch output {:class=>"LogStash::Outputs::ElasticSearch", :hosts=>["http://localhost:9200"]} [INFO ] 2019-08-02 18:29:21.589 [Ruby-0-Thread-9: :1] elasticsearch - Using default mapping template [INFO ] 2019-08-02 18:29:21.696 [Ruby-0-Thread-5: :1] elasticsearch - Attempting to install template {:manage_template=>{"index_patterns"=>"logstash-*", "version"=>60001, "settings"=>{"index.refresh_interval"=>"5s", "number_of_shards"=>1}, "mappings"=>{"dynamic_templates"=>[{"message_field"=>{"path_match"=>"message", "match_mapping_type"=>"string", "mapping"=>{"type"=>"text", "norms"=>false}}}, {"string_fields"=>{"match"=>"*", "match_mapping_type"=>"string", "mapping"=>{"type"=>"text", "norms"=>false, "fields"=>{"keyword"=>{"type"=>"keyword", "ignore_above"=>256}}}}}], "properties"=>{"@timestamp"=>{"type"=>"date"}, "@version"=>{"type"=>"keyword"}, "geoip"=>{"dynamic"=>true, "properties"=>{"ip"=>{"type"=>"ip"}, "location"=>{"type"=>"geo_point"}, "latitude"=>{"type"=>"half_float"}, "longitude"=>{"type"=>"half_float"}}}}}}} [INFO ] 2019-08-02 18:29:21.769 [Ruby-0-Thread-7: :1] elasticsearch - Attempting to install template {:manage_template=>{"index_patterns"=>"logstash-*", "version"=>60001, "settings"=>{"index.refresh_interval"=>"5s", "number_of_shards"=>1}, "mappings"=>{"dynamic_templates"=>[{"message_field"=>{"path_match"=>"message", "match_mapping_type"=>"string", "mapping"=>{"type"=>"text", "norms"=>false}}}, {"string_fields"=>{"match"=>"*", "match_mapping_type"=>"string", "mapping"=>{"type"=>"text", "norms"=>false, "fields"=>{"keyword"=>{"type"=>"keyword", "ignore_above"=>256}}}}}], "properties"=>{"@timestamp"=>{"type"=>"date"}, "@version"=>{"type"=>"keyword"}, "geoip"=>{"dynamic"=>true, "properties"=>{"ip"=>{"type"=>"ip"}, "location"=>{"type"=>"geo_point"}, "latitude"=>{"type"=>"half_float"}, "longitude"=>{"type"=>"half_float"}}}}}}} [INFO ] 2019-08-02 18:29:21.771 [Ruby-0-Thread-9: :1] elasticsearch - Attempting to install template {:manage_template=>{"index_patterns"=>"logstash-*", "version"=>60001, "settings"=>{"index.refresh_interval"=>"5s", "number_of_shards"=>1}, "mappings"=>{"dynamic_templates"=>[{"message_field"=>{"path_match"=>"message", "match_mapping_type"=>"string", "mapping"=>{"type"=>"text", "norms"=>false}}}, {"string_fields"=>{"match"=>"*", "match_mapping_type"=>"string", "mapping"=>{"type"=>"text", "norms"=>false, "fields"=>{"keyword"=>{"type"=>"keyword", "ignore_above"=>256}}}}}], "properties"=>{"@timestamp"=>{"type"=>"date"}, "@version"=>{"type"=>"keyword"}, "geoip"=>{"dynamic"=>true, "properties"=>{"ip"=>{"type"=>"ip"}, "location"=>{"type"=>"geo_point"}, "latitude"=>{"type"=>"half_float"}, "longitude"=>{"type"=>"half_float"}}}}}}} [WARN ] 2019-08-02 18:29:21.871 [[main]-pipeline-manager] LazyDelegatingGauge - A gauge metric of an unknown type (org.jruby.specialized.RubyArrayOneObject) has been create for key: cluster_uuids. This may result in invalid serialization. It is recommended to log an issue to the responsible developer/development team. [INFO ] 2019-08-02 18:29:21.878 [[main]-pipeline-manager] javapipeline - Starting pipeline {:pipeline_id=>"main", "pipeline.workers"=>1, "pipeline.batch.size"=>125, "pipeline.batch.delay"=>50, "pipeline.max_inflight"=>125, :thread=>"#<Thread:0x470bf1ca run>"} [INFO ] 2019-08-02 18:29:22.351 [[main]-pipeline-manager] javapipeline - Pipeline started {"pipeline.id"=>"main"} [INFO ] 2019-08-02 18:29:22.721 [Ruby-0-Thread-1: /usr/share/logstash/lib/bootstrap/environment.rb:6] agent - Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]} [INFO ] 2019-08-02 18:29:23.798 [Api Webserver] agent - Successfully started Logstash API endpoint {:port=>9600} /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/rufus-scheduler-3.0.9/lib/rufus/scheduler/cronline.rb:77: warning: constant ::Fixnum is deprecated /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/rufus-scheduler-3.0.9/lib/rufus/scheduler/cronline.rb:77: warning: constant ::Fixnum is deprecated /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/rufus-scheduler-3.0.9/lib/rufus/scheduler/cronline.rb:77: warning: constant ::Fixnum is deprecated [INFO ] 2019-08-02 18:30:02.333 [Ruby-0-Thread-22: /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/rufus-scheduler-3.0.9/lib/rufus/scheduler/jobs.rb:284] jdbc - (0.042932s) SELECT * FROM pg_stat_user_indexes [INFO ] 2019-08-02 18:30:02.340 [Ruby-0-Thread-23: /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/rufus-scheduler-3.0.9/lib/rufus/scheduler/jobs.rb:331] jdbc - (0.043178s) SELECT * FROM pg_stat_user_tables [INFO ] 2019-08-02 18:30:02.340 [Ruby-0-Thread-24: :1] jdbc - (0.036469s) SELECT * FROM pg_stat_database ...

      Se o Logstash não mostrar nenhum erro e registrar com êxito as linhas Selecionadas (SELECT) dos três bancos de dados, suas métricas serão enviadas ao Elasticsearch. Se você obtiver um erro, verifique todos os valores no arquivo de configuração para garantir que a máquina na qual você está executando o Logstash possa se conectar ao banco de dados gerenciado.

      O Logstash continuará importando os dados em horários especificados. Você pode pará-lo com segurança pressionando CTRL+C.

      Como mencionado anteriormente, quando iniciado como um serviço, o Logstash executa automaticamente todos os arquivos de configuração encontrados em /etc/logstash/conf.d em segundo plano. Execute o seguinte comando para iniciá-lo como um serviço:

      • sudo systemctl start logstash

      Neste passo, você executou o Logstash para verificar se ele pode se conectar ao seu banco de dados e coletar dados. Em seguida, você visualizará e explorará alguns dos dados estatísticos no Kibana.

      Passo 4 — Explorando os Dados Importados no Kibana

      Nesta seção, você verá como você pode explorar os dados estatísticos que descrevem o desempenho do seu banco de dados no Kibana.

      No seu navegador, navegue até a instalação do Kibana que você configurou como pré-requisito. Você verá a página de boas-vindas padrão.

      Kibana - Default Welcome Page

      Para interagir com os índices do Elasticsearch no Kibana, você precisará criar um padrão de índice ou Index patterns. Index patterns especificam em quais índices o Kibana deve operar. Para criar um, pressione o último ícone (chave inglesa) na barra lateral vertical esquerda para abrir a página Management. Em seguida, no menu esquerdo, clique em Index Patterns abaixo de Kibana.. Você verá uma caixa de diálogo para criar um padrão de índice.

      Kibana - Add Index Pattern

      Aqui estão listados os três índices para os quais o Logstash está enviando estatísticas. Digite pg_stat_database na caixa de entrada Index Pattern e pressione Next step. Você será solicitado a selecionar um campo que armazene tempo, para poder restringir seus dados posteriormente por um intervalo de tempo. No menu suspenso, selecione @timestamp.

      Kibana - Index Pattern Timestamp Field

      Clique em Create index pattern para concluir a criação do padrão de índice. Agora você poderá explorá-lo usando o Kibana. Para criar uma visualização, clique no segundo ícone na barra lateral e, em seguida, em Create new visualization. Selecione a visualização Line quando o formulário aparecer e escolha o padrão de índice que você acabou de criar (pg_stat_database). Você verá uma visualização vazia.

      Kibana - Empty Visualisation

      Na parte central da tela está o gráfico resultante — o painel do lado esquerdo governa sua geração a partir da qual você pode definir os dados para os eixos X e Y. No lado superior direito da tela, está o seletor de período. A menos que você escolha especificamente outro intervalo ao configurar os dados, esse intervalo será mostrado no gráfico.

      Agora você visualizará o número médio de tuplas de dados inseridas (INSERT) em minutos no intervalo especificado. Clique em Y-Axis em Metrics no painel à esquerda para expandir. Selecione Average ou média como Aggregation e selecione tup_inserted como Field ou campo. Isso preencherá o eixo Y do gráfico com os valores médios.

      Em seguida, clique em X-Axis em Buckets. Para Aggregation, escolha Date Histogram. @timestamp deve ser selecionado automaticamente como o Field. Em seguida, pressione o botão play azul na parte superior do painel para gerar seu gráfico. Se o seu banco de dados for novo e não for usado, você não verá nada ainda. Em todos os casos, no entanto, você verá um retrato preciso do uso do banco de dados.

      O Kibana suporta muitas outras formas de visualização — você pode explorar outras formas na documentação do Kibana. Você também pode adicionar os dois índices restantes, mencionados no Passo 2 ao Kibana para poder visualizá-los também.

      Neste passo, você aprendeu como visualizar alguns dos dados estatísticos do PostgreSQL, usando o Kibana.

      Passo 5 — (Opcional) Fazendo Benchmark Usando pgbench

      Se você ainda não trabalhou no seu banco de dados fora deste tutorial, você pode concluir esta etapa para criar visualizações mais interessantes usando o pgbench para fazer benchmark do seu banco de dados. O pgbench executará os mesmos comandos SQL repetidamente, simulando o uso do banco de dados no mundo real por um cliente real.

      Você primeiro precisará instalar o pgbench executando o seguinte comando:

      • sudo apt install postgresql-contrib -y

      Como o pgbench irá inserir e atualizar dados de teste, você precisará criar um banco de dados separado para ele. Para fazer isso, vá para a guia Users & Databases no Painel de Controle do seu banco de dados gerenciado e role para baixo até a seção Databases. Digite pgbench como o nome do novo banco de dados e pressione Save. Você passará esse nome, bem como as informações de host, porta e nome de usuário para o pgbench.

      Accessing Databases section in DO control panel

      Antes de executar de fato o pgbench, você precisará executá-lo com a flag -i para inicializar seu banco de dados:

      • pgbench -h host -p port -U username -i pgbench

      Você precisará substituir host pelo seu endereço de host, port pela porta à qual você pode se conectar ao seu banco de dados e username com o nome do usuário do banco de dados. Você pode encontrar todos esses valores no painel de controle do seu banco de dados gerenciado.

      Observe que o pgbench não possui um argumento de senha; em vez disso, você será solicitado sempre que executá-lo.

      A saída terá a seguinte aparência:

      Output

      NOTICE: table "pgbench_history" does not exist, skipping NOTICE: table "pgbench_tellers" does not exist, skipping NOTICE: table "pgbench_accounts" does not exist, skipping NOTICE: table "pgbench_branches" does not exist, skipping creating tables... 100000 of 100000 tuples (100%) done (elapsed 0.16 s, remaining 0.00 s) vacuum... set primary keys... done.

      O pgbench criou quatro tabelas que serão usadas para o benchmarking e as preencheu com algumas linhas de exemplo. Agora você poderá executar benchmarks.

      Os dois argumentos mais importantes que limitam por quanto tempo o benchmark será executado são -t, que especifica o número de transações a serem concluídas, e -T, que define por quantos segundos o benchmark deve ser executado. Essas duas opções são mutuamente exclusivas. No final de cada benchmark, você receberá estatísticas, como o número de transações por segundo (tps).

      Agora, inicie um benchmark que durará 30 segundos executando o seguinte comando:

      • pgbench -h host -p port -U username pgbench -T 30

      A saída será semelhante a:

      Output

      starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 30 s number of transactions actually processed: 7602 latency average = 3.947 ms tps = 253.382298 (including connections establishing) tps = 253.535257 (excluding connections establishing)

      Nesta saída, você vê as informações gerais sobre o benchmark, como o número total de transações executadas. O efeito desses benchmarks é que as estatísticas enviadas pelo Logstash para o Elasticsearch refletirão esse número, o que tornará as visualizações no Kibana mais interessantes e mais próximas dos gráficos do mundo real. Você pode executar o comando anterior mais algumas vezes e talvez alterar a duração.

      Quando terminar, vá para o Kibana e clique em Refresh no canto superior direito. Agora você verá uma linha diferente da anterior, que mostra o número de INSERTs. Sinta-se à vontade para alterar o intervalo de tempo dos dados mostrados, alterando os valores no seletor posicionado acima do botão de atualização. Aqui está como o gráfico pode se apresentar após vários benchmarks de duração variável:

      Kibana - Visualization After Benchmarks

      Você usou o pgbench para fazer benchmark em seu banco de dados e avaliou os gráficos resultantes no Kibana.

      Conclusão

      Agora você tem a pilha Elastic instalada em seu servidor e configurada para coletar regularmente dados estatísticos do banco de dados PostgreSQL gerenciado. Você pode analisar e visualizar os dados usando o Kibana, ou algum outro software adequado, que o ajudará a reunir informações valiosas e correlações do mundo real sobre o desempenho do seu banco de dados.

      Para obter mais informações sobre o que você pode fazer com o banco de dados gerenciado do PostgreSQL, visite a documentação de produto.



      Source link