Quão profundo devemos ir com isso? Começo dizendo que, até o momento em que escrevo, consegui localizar apenas 3 livros na Amazon sobre PostgreSQL na nuvem e 117 discussões nas listas de discussão do PostgreSQL sobre o Aurora PostgreSQL. Isso não parece muito, e me deixa, o curioso usuário final do PostgreSQL, com a documentação oficial como o único lugar onde eu poderia realmente aprender um pouco mais. Como não tenho capacidade, nem conhecimento para me aventurar muito mais profundamente, existe o AWS re:Invent 2018 para quem procura esse tipo de emoção. Posso me contentar com o artigo de Werner sobre quóruns.
Para me aquecer, comecei na página inicial do Aurora PostgreSQL, onde observei que o benchmark mostrando que o Aurora PostgreSQL é três vezes mais rápido que um PostgreSQL padrão executado no mesmo hardware remonta ao PostgreSQL 9.6. Como aprendi mais tarde, 9.6.9 é atualmente a opção padrão ao configurar um novo cluster. Essa é uma notícia muito boa para quem não quer ou não pode atualizar imediatamente. E por que apenas 99,99% de disponibilidade? Uma explicação pode ser encontrada no artigo de Bruce Momjian.
Compatibilidade
De acordo com a AWS, o Aurora PostgreSQL é um substituto imediato para o PostgreSQL, e a documentação afirma:
O código, as ferramentas e os aplicativos que você usa hoje com seus bancos de dados MySQL e PostgreSQL existentes podem ser usados com o Aurora.
Isso é reforçado pelas perguntas frequentes do Aurora:
Isso significa que a maioria dos códigos, aplicativos, drivers e ferramentas que você já usa hoje com seus bancos de dados PostgreSQL podem ser usados com o Aurora com pouca ou nenhuma alteração. O mecanismo de banco de dados do Amazon Aurora foi projetado para ser compatível com fio com PostgreSQL 9.6 e 10 e oferece suporte ao mesmo conjunto de extensões PostgreSQL que são compatíveis com RDS para PostgreSQL 9.6 e 10, facilitando a movimentação de aplicativos entre os dois mecanismos.
“a maioria” no texto acima sugere que não há uma garantia de 100%, caso em que aqueles que buscam certeza devem considerar a compra de suporte técnico de parceiros AWS Professional Services ou Aamazon Aurora. Como uma observação lateral, notei que nenhum dos provedores de hospedagem profissionais do PostgreSQL que empregam os principais contribuidores da comunidade estão nessa lista.
Na página de perguntas frequentes do Aurora, também aprendemos que o Aurora PostgreSQL oferece suporte às mesmas extensões que o RDS, que, por sua vez, lista a maioria das extensões da comunidade e alguns extras.
Conceitos
Como parte do Amazon RDS, o Aurora PostgreSQL vem com sua própria terminologia:
- Cluster:uma instância de banco de dados primária no modo de leitura/gravação e zero ou mais réplicas do Aurora. O banco de dados primário geralmente é rotulado como Master em `diagramas da AWS`_ ou Writer no Console AWS. Com base no diagrama de referência podemos fazer uma observação interessante:Aurora escreve três vezes. Como a latência entre as AZs geralmente é maior do que dentro da mesma AZ, a transação é considerada confirmada assim que é gravada na cópia de dados na mesma AZ, caso contrário, a latência e possíveis interrupções entre as AZs.
- Volume do cluster:volume de armazenamento do banco de dados virtual abrangendo várias AZs.
- URL Aurora:um par `host:port`.
- Cluster Endpoint:URL do Aurora para o banco de dados primário. Há um endpoint de cluster.
- Reader Endpoint:URL do Aurora para o conjunto de réplicas. Para fazer uma analogia com o DNS é um alias (CNAME). As solicitações de leitura têm balanceamento de carga entre as réplicas disponíveis.
- Custom Endpoint:URL do Aurora para um grupo que consiste em uma ou mais instâncias de banco de dados.
- Ponto de extremidade da instância:URL do Aurora para uma instância de banco de dados específica.
- Versão Aurora:versão do produto retornada por `SELECT AURORA_VERSION();`.
Desempenho e monitoramento do PostgreSQL no AWS Aurora
Dimensionamento
O Aurora PostgreSQL aplica uma configuração de melhor estimativa baseada no tamanho da instância de banco de dados e na capacidade de armazenamento, deixando mais ajustes para o DBA por meio do uso de grupos de parâmetros de banco de dados.
Ao selecionar a instância de banco de dados, baseie sua seleção no valor desejado para max_connections.
Escalonamento
O Aurora PostgreSQL apresenta dimensionamento automático e manual. O dimensionamento horizontal de réplicas de leitura é automatizado por meio do uso de métricas de desempenho. O dimensionamento vertical pode ser automatizado por meio de APIs.
O dimensionamento horizontal deixa o offline por alguns minutos enquanto substitui o mecanismo de computação e executa quaisquer operações de manutenção (atualizações, aplicação de patches). Portanto, a AWS recomenda realizar tais operações durante as janelas de manutenção.
Dimensionar em ambas as direções é muito fácil:
Escala vertical:modificando classe de instância 
Escalonamento horizontal:adicionando réplica de leitor. No nível de armazenamento, o espaço é adicionado em incrementos de 10 G. O armazenamento alocado nunca é recuperado, veja abaixo como resolver essa limitação.
Armazenamento
Conforme mencionado acima, o Aurora PostgreSQL foi projetado para aproveitar os quóruns e melhorar a consistência do desempenho.
Como o armazenamento subjacente é compartilhado por todas as instâncias de banco de dados no mesmo cluster, não são necessárias gravações adicionais em nós de espera. Além disso, adicionar ou remover instâncias de banco de dados não altera os dados subjacentes.
Quer saber o que esses IOs unidades significam na conta mensal? As Perguntas frequentes do Aurora vêm em socorro novamente para explicar o que é um IO é, no contexto de monitoramento e faturamento. Uma E/S de leitura como o equivalente a uma leitura de página de banco de dados de 8KiB e uma E/S de gravação como o equivalente a 4KiB gravados na camada de armazenamento.
Alta simultaneidade
Para aproveitar ao máximo o design de alta simultaneidade do Aurora, é recomendável que os aplicativos sejam configurados para conduzir um grande número de consultas e transações simultâneas.
Os aplicativos projetados para direcionar consultas de leitura e gravação para nós de banco de dados primários e em espera, respectivamente, se beneficiarão do endpoint de réplica de leitor do Aurora PostgreSQL.
As conexões têm balanceamento de carga entre as réplicas de leitura.
O uso de instâncias de banco de dados de endpoints personalizados com mais capacidade pode ser agrupada para executar uma carga de trabalho intensiva, como análises.
Os endpoints de instância de banco de dados podem ser usados para balanceamento de carga refinado ou failover rápido.
Observe que, para que os endpoints de leitor balancem a carga de consultas individuais, cada consulta deve ser enviada como uma nova conexão.
Cache
O Aurora PostgreSQL usa a técnica Survivable Cache Warming que garante que a data no cache do buffer seja preservada, eliminando a necessidade de repovoar ou aquecer o cache após a reinicialização do banco de dados.
Replicação
O tempo de atraso de replicação entre as réplicas é mantido em milissegundos de um dígito. Embora não esteja disponível para o PostgreSQL, é bom saber que o atraso da replicação entre regiões é mantido em 10s de milissegundos.
De acordo com a documentação, o atraso da réplica aumenta durante os períodos de solicitações de gravação pesadas.
Planos de execução de consultas
Com base na suposição de que o desempenho da consulta diminui ao longo do tempo devido a várias alterações no banco de dados, a função desse componente do Aurora PostgreSQL é manter uma lista de planos de execução de consulta aprovados ou rejeitados.
Os planos são aprovados ou rejeitados usando métodos proativos ou reativos.
Quando um plano de execução é marcado como rejeitado, o Query Execution Plan substitui as decisões do otimizador do PostgreSQL e impede que o plano “ruim” seja executado.
Esse recurso requer o Aurora 2.1.0 ou posterior.
Alta disponibilidade e replicação do PostgreSQL no AWS Aurora
Na camada de armazenamento, o Aurora PostgreSQL garante durabilidade replicando cada 10 GB de volume de armazenamento, seis vezes em 3 AZs (cada região consiste normalmente em 3 AZs) usando replicação síncrona física. Isso possibilita que as gravações do banco de dados continuem funcionando mesmo quando 2 cópias de dados são perdidas. A disponibilidade de leitura sobrevive à perda de 3 cópias de dados.
As réplicas de leitura garantem que uma instância primária com falha possa ser rapidamente substituída promovendo uma das 15 réplicas disponíveis. Ao selecionar uma implantação multi-AZ, uma réplica de leitura é criada automaticamente. O failover não requer intervenção do usuário e as operações do banco de dados são retomadas em menos de 30 segundos.
Para implantações single-AZ, o procedimento de recuperação inclui uma restauração do último backup válido conhecido. De acordo com as perguntas frequentes do Aurora, o processo é concluído em menos de 15 minutos se o banco de dados precisar ser restaurado em uma AZ diferente. A documentação não é tão específica, alegando que leva menos de 10 minutos para concluir o processo de restauração.
Nenhuma alteração é necessária no lado do aplicativo para se conectar à nova instância de banco de dados, pois o endpoint do cluster não muda durante uma promoção de réplica ou restauração de instância.
Etapa 1:exclua a instância primária para forçar um failover:
Failover automático Etapa 1:excluir primário Etapa 2:failover automático concluído
Failover automático Etapa 2:failover concluído. Para bancos de dados ocupados, o tempo de recuperação após uma reinicialização ou falha é drasticamente reduzido, pois o Aurora PostgreSQL não precisa reproduzir os logs de transação.
Como parte do serviço totalmente gerenciado, os blocos e discos de dados ruins são substituídos automaticamente.
O failover quando existem réplicas leva até 120 segundos com tempo geralmente inferior a 60 segundos. Tempos de recuperação mais rápidos podem ser alcançados quando as condições de failover são pré-determinadas, caso em que as réplicas podem receber prioridades de failover.
O Aurora PostgreSQL funciona bem com o Amazon RDS – uma instância do Aurora pode atuar como uma réplica de leitura para uma instância primária do RDS.
O Aurora PostgreSQL oferece suporte à replicação lógica que, assim como na versão da comunidade, pode ser usada para superar as limitações de replicação integradas. Não há automação ou interface de console da AWS.
Segurança para PostgreSQL no AWS Aurora
No nível da rede, o Aurora PostgreSQL aproveita os principais componentes da AWS, VPC para isolamento de rede na nuvem e grupos de segurança para controle de acesso à rede.
Não há acesso de superusuário. Ao criar um cluster, o Aurora PostgreSQL cria uma conta mestra com um subconjunto de permissões de superusuário:
[email protected]:5432 postgres> \du+ postgres
List of roles
Role name | Attributes | Member of | Description
-----------+-------------------------------+-----------------+-------------
postgres | Create role, Create DB +| {rds_superuser} |
| Password valid until infinity | |Para proteger os dados em trânsito, o Aurora PostgreSQL oferece suporte nativo a SSL/TLS que pode ser configurado por instância de banco de dados.
Todos os dados em repouso podem ser criptografados com impacto mínimo no desempenho. Isso também se aplica a backups, instantâneos e réplicas.
Criptografia em repouso. A autenticação é controlada por políticas do IAM, e a marcação permite maior controle sobre o que os usuários têm permissão para fazer e quais recursos.
As chamadas de API usadas por todos os serviços de nuvem são registradas no CloudTrail.
O Gerenciamento de Senhas Restritas do lado do cliente está disponível por meio do parâmetro rds.restrict_password_commands.
Backup e recuperação do PostgreSQL no AWS Aurora
Os backups são ativados por padrão e não podem ser desativados. Eles fornecem recuperação pontual usando um instantâneo diário completo como backup básico.
A restauração de um backup automatizado tem algumas desvantagens:o tempo de restauração pode ser de várias horas e a perda de dados pode ser de até 5 minutos antes da interrupção. As implantações do Amazon RDS Multi-AZ resolvem esse problema promovendo uma réplica de leitura para primária, sem perda de dados.
Os instantâneos de banco de dados são rápidos e não afetam o desempenho do cluster. Eles podem ser copiados ou compartilhados com outros usuários.
Tirar um instantâneo é quase instantâneo:
Hora do instantâneo. A restauração de um instantâneo também é rápida. Compare com o PITR:
Backups e snapshots são armazenados no S3, que oferece onze 9's de durabilidade.
Além de backups e snapshots, o Aurora PostgreSQL permite que bancos de dados sejam clonados. Este é um método eficiente para criar cópias de grandes conjuntos de dados. Por exemplo, a clonagem de vários terabytes de dados leva apenas alguns minutos e não há impacto no desempenho.
Aurora PostgreSQL - Demonstração de recuperação pontual
Conectando-se ao cluster:
~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.Preencha uma tabela com dados:
[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE
[email protected]:5432 postgres> select * from s9s;
id | msg | created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)Inicie a restauração:
Recuperação pontual:inicie a restauração. 
Quando a restauração estiver concluída, faça login e verifique:
~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
[email protected]:5432 postgres> select * from s9s;
id | msg | created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)Práticas recomendadas
Monitoramento e auditoria
- Integre os fluxos de atividade do banco de dados com o monitoramento de terceiros para monitorar a atividade do banco de dados para conformidade e requisitos regulatórios.
- Um serviço de banco de dados totalmente gerenciado não significa falta de responsabilidade — defina métricas para monitorar a CPU, RAM, espaço em disco, rede e conexões de banco de dados.
- O Aurora PostgreSQL integra-se à ferramenta de monitoramento padrão da AWS CloudWatch, além de fornecer monitores adicionais para Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication e também para RDS Metrics que podem ser agrupados ainda mais por RDS Dimensions.
- Monitore a carga média de banco de dados de sessões ativas por espera por sinais de sobrecarga de conexões, consultas SQL que precisam de ajuste, contenção de recursos ou uma classe de instância de banco de dados subdimensionada.
- Configurar notificações de eventos.
- Configure os parâmetros do registro de erros.
- Monitore as alterações de configuração nos componentes do cluster de banco de dados:instâncias, grupos de sub-rede, instantâneos, grupos de segurança.
Replicação
- Use particionamento de tabela nativa para cargas de trabalho que excedem a classe máxima de instância de banco de dados e a capacidade de armazenamento
Criptografia
- O banco de dados criptografado deve ter backups ativados para garantir que os dados possam ser restaurados caso a chave de criptografia seja revogada.
Conta principal
- Não use o psql para alterar a senha do usuário mestre.
Dimensionamento
- Considere usar diferentes classes de instância em um cluster para reduzir custos.
Grupos de parâmetros
- Ajuste usando grupos de parâmetros para economizar $$$.
Demonstração de grupos de parâmetros
Configurações atuais:
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)Crie um novo grupo de parâmetros e defina o novo valor para todo o cluster:
Atualizando shared_buffers em todo o cluster. Associe o grupo de parâmetros personalizado ao cluster:
Reinicie o gravador e verifique o valor:
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)- Definir o fuso horário local
Por padrão, o fuso horário está em UTC:
[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)Configurando o novo fuso horário:
Configurando fuso horário E depois verifique:
[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)Observe que a lista de valores de fuso horário aceitos pelo Amazon Aurora não são os conjuntos de fuso horário encontrados no PostgreSQL upstream.
- Revise os parâmetros de instância que são substituídos por parâmetros de cluster
- Use a ferramenta de comparação de grupos de parâmetros.
Fotos
- Evite cobranças adicionais de armazenamento compartilhando os instantâneos com outras contas para permitir a restauração em seus respectivos ambientes.
Manutenção
- Altere a janela de manutenção padrão de acordo com a programação da organização.
Failover
- Melhore o tempo de recuperação configurando o Cluster Cache Management.
- Diminua os valores de manutenção de atividade TCP do kernel no cliente e configure o cache DNS e o TTL do aplicativo e as strings de conexão do PostgreSQL.
DBA Cuidado!
Além das limitações conhecidas, evite ou esteja ciente do seguinte:
Criptografia
- Depois que um banco de dados é criado, o estado de criptografia não pode ser alterado.
Aurora sem servidor
- No momento, a versão PostgreSQL do Aurora Serverless está disponível apenas em visualização limitada.
Consulta paralela
- O Amazon Parallel Query não está disponível, embora o recurso com o mesmo nome esteja disponível desde o PostgreSQL 9.6.
Pontos de extremidade
Do Gerenciamento de conexões da Amazon:
- 5 endpoints personalizados por cluster
- Os nomes de endpoints personalizados não podem exceder 63 caracteres
- Os nomes dos endpoints do cluster são exclusivos na mesma região
- Como visto na captura de tela acima (aurora-custom-endpoint-details) READER e ANY tipos de endpoint personalizados não estão disponíveis, use a CLI
- Os endpoints personalizados não sabem que as réplicas estão temporariamente indisponíveis
Replicação
- Ao promover uma réplica para primária, as conexões por meio do Reader Endpoint podem continuar sendo direcionadas por um breve período para a réplica promovida.
- Não há suporte para réplicas entre regiões
- Embora lançada no final de novembro de 2017, a visualização do Amazon Aurora Multi-Master ainda não está disponível para PostgreSQL
- Observe a degradação do desempenho quando a replicação lógica estiver habilitada no cluster.
- A replicação lógica requer um mecanismo PostgreSQL publicado em execução 10.6 ou posterior.
Armazenamento
- O armazenamento máximo alocado não diminui quando os dados são excluídos, nem o espaço é recuperado com a restauração de instantâneos. A única maneira de recuperar espaço é realizando um dump lógico em um novo cluster.
Backup e recuperação
- A retenção de backups não é estendida enquanto o cluster está parado.
- O período máximo de retenção é de 35 dias. Use instantâneos manuais para um período de retenção mais longo.
- recuperação pontual para um novo cluster de banco de dados.
- breve interrupção de leituras durante failover para réplicas.
- Os cenários de recuperação de desastres não estão disponíveis entre regiões.
Fotos
- A restauração do snapshot cria um novo endpoint (snapshots só podem ser restaurados para um novo cluster).
- Após uma restauração de instantâneo, os endpoints personalizados devem ser recriados.
- A restauração de instantâneos redefine o fuso horário local para UTC.
- A restauração de instantâneos não preserva os grupos de segurança personalizados.
- Os instantâneos podem ser compartilhados com no máximo 20 IDs de conta da AWS.
- Os instantâneos não podem ser compartilhados entre regiões.
- Snapshots incrementais são sempre copiados como snapshots completos, entre regiões e dentro da mesma região.
- Copiar snapshots entre regiões não preserva os grupos de parâmetros não padrão.
Faturamento
- A conta de 10 minutos se aplica a novas instâncias, bem como após uma mudança de capacidade (computação ou armazenamento).
Autenticação
- O uso da autenticação de banco de dados do IAM impõe um limite no número de conexões por segundo.
- A conta mestra tem certos privilégios de superusuário revogados.
Iniciando e Parando
Da visão geral de parar e iniciar um cluster de banco de dados do Aurora:
- Os clusters não podem ser interrompidos indefinidamente, pois são iniciados automaticamente após sete dias.
- Instâncias de banco de dados individuais não podem ser interrompidas.
Atualizações
- Não há suporte para atualizações de versão principal no local.
- As alterações de grupo de parâmetros para instância de banco de dados e cluster de banco de dados levam pelo menos 5 minutos para serem propagadas.
Clonagem
- 15 clones por banco de dados (original ou cópia).
- Os clones não são removidos ao excluir o banco de dados de origem.
Escalonamento
- O Auto-Scaling exige que todas as réplicas estejam disponíveis.
- Só pode haver `uma política de escalonamento automático`_ por métrica por cluster.
- O dimensionamento horizontal da instância de banco de dados primária (classe de instância) não é totalmente automático. Antes de dimensionar o cluster aciona um failover automático para uma das réplicas. Após a conclusão do dimensionamento, a nova instância deve ser promovida manualmente de leitor para gravador:
Nova instância deixada no modo de leitor após a alteração da classe da instância de banco de dados.
Monitoramento
- A publicação de logs do PostgreSQL no CloudWatch requer uma versão mínima do mecanismo de banco de dados 9.6.6 e 10.4.
- Apenas algumas métricas do Aurora estão disponíveis no Console do RDS e outras métricas têm nomes e unidades de medida diferentes.
- Por padrão, os logs de monitoramento avançado são mantidos no CloudWatch por 30 dias.
- As métricas do Cloudwatch e do Enhanced Monitoring serão diferentes, pois coletam dados do hipervisor e, respectivamente, do agente em execução na instância.
- Performance Insights_ agrega as métricas em todos os bancos de dados em uma instância de banco de dados.
- As instruções SQL são limitadas a 500 caracteres quando visualizadas com a CLI e API do AWS Performance Insights.
Migração
- Somente os snapshots de banco de dados não criptografados RDS podem ser criptografados em repouso.
- As migrações que usam a técnica Aurora Read Replica levam várias horas por TiB.
Dimensionamento
- A menor classe de instância disponível é db.t3.medium e a maior db.r5.24xlarge. Para comparação, o mecanismo MySQL oferece db.t2.small e db.t2.medium, mas não db.r5.24xlarge no intervalo superior.
- limite máximo de max_connections é 262.143.
Gerenciamento do plano de consulta
- Declarações dentro de funções PL/pgSQL não são suportadas.
Migração
O Aurora PostgreSQL não fornece serviços de migração direta, mas a tarefa é transferida para um produto especializado da AWS, o AWS DMS.
Conclusão
Como um substituto totalmente gerenciado para o PostgreSQL upstream, o Amazon Aurora PostgreSQL aproveita as tecnologias que alimentam a nuvem AWS para remover a complexidade necessária para configurar serviços como dimensionamento automático, balanceamento de carga de consulta e dados de baixo nível replicação, backups incrementais e criptografia.
A arquitetura e uma abordagem conservadora para atualizar o mecanismo PostgreSQL fornecem o desempenho e a estabilidade que as organizações de pequeno a grande porte procuram.
As limitações inerentes são apenas uma prova de que construir um Banco de Dados como Serviço em larga escala é uma tarefa complexa, deixando os Provedores de Hospedagem PostgreSQL altamente especializados com um nicho de mercado que eles podem explorar.
