Introdução ao Banco de Dados do Azure para PostgreSQL
O Banco de Dados do Azure para PostgreSQL está disponível em versões multiservidor.
Como um desenvolvedor de banco de dados com muitos anos de experiência na execução e no gerenciamento de instalações locais do PostgreSQL, você deseja explorar como o Banco de Dados do Azure para PostgreSQL dá suporte e dimensiona seus recursos.
Nesta unidade, você explorará as opções de preço, suporte de versão, replicação e dimensionamento do Banco de Dados do Azure para PostgreSQL.
Banco de Dados do Azure para PostgreSQL
O serviço Banco de Dados do Azure para PostgreSQL é uma implementação da versão da comunidade do PostgreSQL. O serviço fornece os recursos comuns usados por sistemas PostgreSQL típicos, incluindo suporte geoespacial e pesquisa de texto completo.
A Microsoft adaptou o PostgreSQL para a plataforma Azure, e ele está integrado a muitos serviços do Azure. O serviço Banco de Dados do Azure para PostgreSQL é totalmente gerenciado pela Microsoft. A Microsoft cuida das atualizações e patches para o software e fornece um SLA de 99,99% de disponibilidade. Isso significa que, usando o serviço, você pode apenas se concentrar nos bancos de dados e aplicativos em execução.
Você pode implantar vários bancos de dados em cada instância desse serviço.
Tipos de preço
Ao criar uma instância do serviço Banco de Dados do Azure para PostgreSQL, você especifica os recursos de computação e armazenamento que deseja alocar escolhendo um Tipo de Preço. Um tipo de preço combina o número de núcleos de processador virtual, a quantidade de armazenamento disponível e várias opções de backup. Quanto mais recursos você alocar, maior será o custo.
O serviço Banco de Dados do Azure para PostgreSQL usa o armazenamento para armazenar arquivos de banco de dados, arquivos temporários, logs de transações e logs do servidor. Como alternativa, você pode especificar que deseja que o armazenamento disponível seja aumentado quando chegar perto da capacidade atual. Se você não escolher essa opção, os servidores que ficarem sem armazenamento continuarão em execução, mas funcionarão como somente leitura.
O portal do Azure agrupa os tipos de preço em três intervalos amplos:
- Básico, que é adequado para pequenos sistemas e ambientes de desenvolvimento, mas tem desempenho variável de E/S.
- Uso geral, que fornece desempenho previsível, até 6.000 IOPS, dependendo do número de núcleos de processador e do espaço de armazenamento disponível.
- Memória otimizada, que usa até 32 núcleos de processador virtual com otimização de memória e também fornece desempenho previsível de até 6.000 IOPS.
A Microsoft também tem a opção de grande armazenamento em versão prévia, que pode provisionar até 16 TB de armazenamento e permitir até 20.000 IOPS.
Você pode ajustar o número de núcleos de processador e armazenamento de que precisa. Você pode escalar horizontal e verticalmente os recursos de processamento. Não é possível escalar o armazenamento verticalmente e alternar entre os tipos de preço Uso Geral e Otimizado para memória, conforme necessário, depois de criar seus bancos de dados. Você paga apenas pelo que usa.
Observação
Se você alterar o número de núcleos de processador, o Azure criará um novo servidor com essa alocação de computação. Quando o servidor está em execução, as conexões do cliente são alternadas para o novo servidor. Essa alternância pode levar até um minuto. Durante esse intervalo, nenhuma nova conexão poderá ser feita, e todas as transações em andamento serão revertidas.
Se você alterar apenas o tamanho do armazenamento das opções de backup, não haverá interrupção no serviço.
O tipo de preço e os recursos de processamento alocados determinam o número máximo de conexões simultâneas às quais o serviço dará suporte. Por exemplo, se você escolher o tipo de preço Uso Geral e alocar 64 núcleos virtuais, o serviço permitirá 1.900 conexões simultâneas. A camada Básica, com dois núcleos virtuais, lida com até 100 conexões simultâneas. O Azure em si requer cinco dessas conexões para monitorar o servidor. Se você exceder o número de conexões disponíveis, os clientes receberão o erro FATAL: desculpe, já há muitos clientes.
Os preços podem ser alterados. Visite a página de Preços do Banco de Dados do Azure para PostgreSQL para obter as informações mais recentes.
Parâmetros do Servidor
Em uma instalação local do PostgreSQL, defina os parâmetros de configuração do servidor no arquivo postgresql.conf. Use o Banco de Dados do Azure para PostgreSQL para mudar parâmetros de configuração por meio da página Parâmetros do servidor. Nem todos os parâmetros para uma instalação local do PostgreSQL são relevantes para o Banco de Dados do Azure para PostgreSQL, portanto, a página de parâmetros do servidor lista apenas os parâmetros que são apropriados para o Azure.
Alterações nos parâmetros marcados como Dinâmicos entram em vigor imediatamente. Os parâmetros estáticos exigem uma reinicialização do servidor. Reinicie o servidor usando o botão Reiniciar na página Visão geral no portal:
Alta disponibilidade
O Banco de Dados do Azure para PostgreSQL é um serviço altamente disponível. Ele contém mecanismos internos de detecção de falha e failover. Se um nó de processamento parar devido a um problema de hardware ou software, um novo nó será ativado para substituí-lo. Todas as conexões que estiverem usando esse nó serão descartadas, mas automaticamente abertas no novo nó. Todas as transações executadas pelo nó com falha serão revertidas. Por esse motivo, você sempre deve garantir que os clientes estejam configurados para detectar e repetir operações com falha.
Versões compatíveis do PostgreSQL
O serviço Banco de Dados do Azure para PostgreSQL atualmente aceita a versão 11 do PostgreSQL, sendo a versão 9.5 a mais antiga aceita. Especifique qual versão do PostgreSQL usa ao criar uma instância do serviço. A Microsoft pretende atualizar o serviço à medida que novas versões do PostgreSQL forem disponibilizadas e manterá a compatibilidade com as duas versões principais anteriores.
O Azure gerencia automaticamente as atualizações para seus bancos de dados entre versões secundárias do PostgreSQL, mas não as versões principais. Por exemplo, se você tiver um banco de dados que usa o PostgreSQL versão 10, o Azure poderá atualizar automaticamente o banco de dados para a versão 10.1. Se você quiser alternar para a versão 11, deverá exportar os dados dos bancos de dado na instância do serviço atual, criar uma nova instância do serviço Banco de Dados do Azure para PostgreSQL e importar seus dados para essa nova instância.
Nós coordenadores e de trabalho
Os dados são fragmentados e distribuídos entre nós de trabalho. O mecanismo de consulta no coordenador pode paralelizar consultas complexas, direcionando o processamento para os nós de trabalho apropriados. Os nós de trabalho são selecionados de acordo com os fragmentos que mantêm os dados que estão sendo processados. Em seguida, o coordenador acumula os resultados dos nós de trabalho antes de enviá-los de volta ao cliente. Consultas mais diretas podem ser executadas usando apenas um único nó de trabalho. Os clientes também se conectam ao coordenador e nunca se comunicam diretamente com um nó de trabalho.
Você pode escalar horizontal e verticalmente o número de nós de trabalho em seu serviço, conforme necessário.
Distribuindo dados
Distribua dados entre nós de trabalho criando tabelas distribuídas. Uma tabela distribuída é dividida em fragmentos, e cada fragmento é alocado para armazenamento em um nó de trabalho. Indique como dividir os dados definindo uma coluna como a coluna de distribuição. Os dados são fragmentados com base nos valores dos dados nesta coluna. Quando você cria uma tabela distribuída, é importante escolher a coluna de distribuição com cuidado. Você deve usar uma coluna com um grande número de valores distintos que normalmente seriam usados para agrupar linhas relacionadas. Por exemplo, em uma tabela para um sistema de comércio eletrônico que armazena informações sobre pedidos de clientes, a ID do cliente pode ser uma coluna de distribuição razoável. Todos os pedidos de um determinado cliente serão mantidos no mesmo fragmento, mas os pedidos de todos os clientes serão distribuídos entre fragmentos.
Você também pode criar tabelas de referência. Essas tabelas contêm dados de pesquisa, como os nomes de cidades ou códigos de status. Uma tabela de referência é replicada em sua totalidade para cada nó de trabalho. Os dados em uma tabela de referência devem ser relativamente estáticos. Cada alteração requer a atualização de todas as cópias da tabela.
Por fim, você pode criar tabelas locais. Uma tabela local não é fragmentada, mas é armazenada no nó coordenador. Use tabelas locais para manter pequenas tabelas com dados que são improváveis de serem exigidas por junções. Os exemplos incluem os nomes de usuários e seus detalhes de logon.
Replicar dados no Banco de Dados do Azure para PostgreSQL
Réplicas somente leitura são úteis para lidar com cargas de trabalho com uso intensivo de leitura. As conexões de cliente podem ser distribuídas entre réplicas, facilitando a carga em uma única instância do serviço. Se os clientes estiverem localizados em diferentes regiões do mundo, você usará a replicação entre regiões para posicionar os dados próximos a cada conjunto de clientes e reduzir a latência.
Você também pode usar réplicas como parte de um plano de contingência para recuperação de desastre. Se o servidor mestre ficar indisponível, você ainda poderá se conectar a uma réplica.
Observação
Se o mestre for perdido ou excluído, todas as réplicas somente leitura se tornarão servidores de leitura/gravação. No entanto, esses servidores serão independentes um do outro, portanto, as alterações feitas nos dados em um servidor não serão copiadas para os servidores restantes.
Estabelecer uma réplica
Uma réplica somente leitura contém uma cópia dos bancos de dados mantidos no servidor original, conhecida como mestre. Use a CLI ou o portal do Azure para criar uma réplica de um mestre.
Quando você cria uma réplica somente leitura, o Azure cria uma nova instância do serviço Banco de Dados do Azure para PostgreSQL e, em seguida, copia os banco de dados do servidor mestre para o novo servidor. A réplica é executada no modo somente leitura. Qualquer tentativa de mudar dados falhará.
Atraso da réplica
A replicação não é síncrona, e as alterações feitas nos dados no servidor mestre podem levar algum tempo para aparecer nas réplicas. Aplicativos cliente que se conectam a réplicas devem ser capazes de lidar com esse nível de consistência eventual. O Azure Monitor permite que você acompanhe o atraso na replicação usando as métricas de atraso máximo entre réplicas e latência de réplica.
Gerenciamento e monitoramento
Você pode usar ferramentas familiares, como o pgAdmin, para se conectar ao Banco de Dados do Azure para PostgreSQL para gerenciar e monitorar seus bancos de dados. No entanto, alguns recursos voltados para o servidor, como executar backup e restauração do servidor, não estão disponíveis porque o servidor é gerenciado e mantido pela Microsoft.
Ferramentas do Azure para o monitoramento do Banco de Dados do Azure para PostgreSQL
O Azure oferece um amplo conjunto de serviços que você usa para monitorar o desempenho do servidor e do banco de dados e solucionar problemas. Esses serviços permitem que você veja como o PostgreSQL está utilizando os recursos do Azure que você alocou. Use essas informações para avaliar se você precisa dimensionar seu sistema, mudar a estrutura de tabelas e índices em seus bancos de dados e visualizar estatísticas de runtime e outros eventos. Os serviços disponíveis incluem:
Azure Monitor. O Banco de Dados do Azure para PostgreSQL oferecem métricas que permitem controlar itens como utilização de CPU e armazenamento, taxas de E/S, ocupação de memória, número de conexões ativas e atraso de replicação:
Logs do servidor. O Azure torna os logs disponíveis para cada servidor PostgreSQL. Você os baixa do portal do Azure:
Repositório de Consultas e Análise de Desempenho de Consultas. O Banco de Dados do Azure para PostgreSQL armazena informações sobre as consultas executadas em bancos de dados no servidor e as salva em um banco de dados chamado azure_sys, no esquema query_store. Consulte a exibição query_store.qs_view para ver essas informações. Por padrão, o Banco de Dados do Azure para PostgreSQL não captura nenhuma informação da consulta, pois ela impõe uma pequena sobrecarga, mas você pode habilitar o acompanhamento definindo a propriedade de servidor pg_qs.query_capture_mode como TODOS ou PRINCIPAIS.
Configure também o Repositório de Consultas para capturar informações sobre consultas que passam tempo aguardando. Uma consulta pode ter que aguardar enquanto outra consulta libera um bloqueio em uma tabela, porque a consulta está executando uma grande quantidade de E/S ou porque a memória está insuficiente. Você vê essas informações na exibição query_store.runtime_stats_view.
Se você preferir ver essas estatísticas em vez de executar instruções SQL, use a Análise de Desempenho de Consultas no portal do Azure:
Recomendações do desempenho. O utilitário recomendações de desempenho, também disponível na portal do Azure, examina as consultas que seus aplicativos estão executando. Ele também examina as estruturas no banco de dados e recomenda a forma de organização dos seus dados, assim como se você deve considerar adicionar ou remover índices.
Conectividade de cliente
O Banco de Dados do Azure para PostgreSQL é executado por trás de um firewall. Para acessar seu serviço e banco de dados, você deve adicionar uma regra de firewall para os intervalos de endereços IP dos quais seus clientes se conectam. Se você precisar acessar o serviço pelo Azure, como um aplicativo em execução usando os Serviços de Aplicativos do Azure, você também deve habilitar o acesso aos serviços do Azure.
Configurar o firewall
A maneira mais simples de configurar o firewall é usar as configurações de Segurança de Conexão para seu serviço no portal do Azure. Adicione uma regra para cada intervalo de endereços IP do cliente. Você também pode usar essa página para impor conexões SSL ao seu serviço.
Clique em Adicionar IP do cliente na barra de ferramentas para adicionar o endereço IP do computador desktop.
Se você tiver configurado réplicas somente leitura, deverá adicionar uma regra de firewall a cada uma para torná-las acessíveis aos clientes.
Bibliotecas de conexão do cliente
Se você estiver gravando seus próprios aplicativos cliente, deverá usar o driver de banco de dados apropriado para se conectar a um banco de dados PostgreSQL. Muitas dessas bibliotecas são dependentes da linguagem de programação. Elas são mantidos por terceiros independentes. O Banco de Dados do Azure para PostgreSQL dá suporte a bibliotecas de cliente para Python, PHP, Node.js, Java, Ruby, Go, C# (.NET), ODBC, C e C++.
Lógica de repetição do cliente
Como mencionado anteriormente, alguns eventos, como o failover durante a recuperação de alta disponibilidade e a expansão dos recursos da CPU, podem causar uma breve perda na conectividade. Todas as transações em andamento serão revertidas. O Banco de Dados do Azure para PostgreSQL redireciona automaticamente um cliente conectado para um nó de trabalho, mas qualquer operação executada pelo cliente nesse momento retornará um erro. Você deve tratar essa ocorrência como uma exceção transitória. O código do aplicativo deve estar preparado para capturar essas exceções e tentar novamente.
Recursos do PostgreSQL no Banco de Dados do Azure para PostgreSQL
O Banco de Dados do Azure para PostgreSQL permite a maioria dos recursos comumente usados por bancos de dados PostgreSQL, mas há algumas exceções. Se você precisar de um recurso incompatível, precisará retrabalhar seu banco de dados e o código do aplicativo para remover essa dependência ou considerar a execução do PostgreSQL em uma máquina virtual. No último caso, você precisará assumir a responsabilidade por gerenciar e manter o servidor.
Extensões compatíveis no Banco de Dados do Azure para PostgreSQL
Grande parte da funcionalidade do PostgreSQL é encapsulada em extensões. As extensões são pacotes de objetos SQL e de código que são armazenados no servidor. Elas podem ser carregadas em um banco de dados usando o comando CREATE EXTENSION. O Banco de Dados do Azure para PostgreSQL atualmente oferece muitas extensões usadas com frequência para:
- Tipos de dados
- Funções
- Pesquisa de texto completo
- Índices (bloom, btree_gist e btree_gin)
- A linguagem plpgsql
- PostGIS
- Muitas funções administrativas
Use os pacotes dblink e postgres_fdw para conectar um servidor PostgreSQL a outro. Isso permite que o código em um servidor acesse os dados mantidos em outro. No Banco de Dados do Azure para PostgreSQL, você só pode se conectar entre servidores criados usando o Banco de Dados do Azure para PostgreSQL. Você não pode criar conexões de saída para servidores PostgreSQL hospedados em outro lugar, como localmente ou em uma máquina virtual.
Observação
A lista de extensões compatíveis está continuamente sob revisão e pode ser alterada. Você vai gerar uma lista das extensões compatíveis com a consulta a seguir. Você não pode criar suas próprias extensões personalizadas e carregá-las no Banco de Dados do Azure para PostgreSQL:
SELECT * FROM pg_available_extensions;
O Banco de Dados do Azure para PostgreSQL inclui o banco de dados TimescaleDB como uma extensão opcional. Esse banco de dados contém funções analíticas orientadas a tempo e outros recursos que permitem cargas de trabalho de série temporal. Para usar esse banco de dados, escolha a opção TIMESCALEDB no parâmetro de servidor shared_preload_libraries e reinicie o servidor.
Suporte a idiomas para procedimentos armazenados e gatilhos
O suporte para idiomas diferentes de plpgsql normalmente exige que você compile o procedimento armazenado ou dispare o código separadamente e carregue a biblioteca compilada no servidor. Principalmente por motivos de segurança, você não pode fazer isso com o Banco de Dados do Azure para PostgreSQL. Se você tiver um código escrito em outras linguagens, terá que transportá-lo para plpgsql.