View a markdown version of this page

Diretrizes de configuração - Amazon Aurora
Configurações do RDS ProxyAlinhar a configuração de aplicações, proxies e bancos de dadosConfiguração do banco de dadosConfiguração da aplicação

Diretrizes de configuração

Esta seção descreve as configurações disponíveis no RDS Proxy e apresenta práticas recomendadas para alinhar a configuração na pilha de aplicações. Essas são diretrizes combinadas para o uso do RDS Proxy com o Amazon RDS e o Amazon Aurora. Observações específicas ao RDS e ao Aurora são chamadas quando aplicável.

A menos que indicado de outra forma, os termos “banco de dados” ou “destino” se referem a um cluster do Aurora, a um cluster de banco de dados multi-AZ do Amazon RDS ou a uma instância do Amazon RDS.

Configurações do RDS Proxy

MaxConnectionsPercent

Valor mínimo Valor máximo Valor padrão
lesser of (1, MaxIdleConnectionsPercent) 100 100

Para obter mais informações, consulte MaxConnectionsPercent.

Essa configuração limita o número de conexões que o Proxy RDS pode estabelecer com o banco de dados de destino, como uma porcentagem do número máximo de conexões permitidas pelo banco de dados. Com o proxy abre conexões de backend conforme necessário, o número real de conexões a qualquer momento pode ser menor que o máximo configurado.

Como a configuração MaxConnectionsPercent é uma porcentagem do limite de conexão do banco de dados, o tamanho do grupo de conexões do proxy segue automaticamente a configuração do banco de dados. Isso significa que não será necessário reconfigurar proxies sempre que redimensionar instâncias de banco de dados ou fazer alterações na configuração. Isso também significa que você precisa estar ciente dos cenários em que as configurações do banco de dados podem mudar, implícita ou explicitamente:

Práticas recomendadas:

  • A configuração padrão de 100% é adequada para bancos de dados que recebem todo o tráfego por meio do proxy e não precisam de espaço livre para acesso administrativo ou outros clientes.

  • Reduza essa configuração quando o banco de dados também receber tráfego diretamente da aplicações (ignorando o proxy) e você não quiser que o proxy consuma todas as conexões ou quando quiser reservar determinado número de conexões para outros fins, como acesso direto pelos administradores do banco de dados.

  • Ao usar o RDS Proxy com clusters do Aurora Global Database e o encaminhamento de gravação habilitado, reduza o valor MaxConnectionsPercent do proxy de acordo com a cota alocada para encaminhamento de gravação. Para ver detalhes, consulte os parâmetros de configuração do encaminhamento de gravação no Aurora MySQL e no Aurora PostgreSQL no Guia do usuário do Amazon Aurora. Essa recomendação se aplica se o proxy estiver atendendo a um cluster na região primária ou secundária do banco de dados global. Como os clusters secundários podem ser promovidos ao perfil principal, é uma boa prática manter as configurações de proxy consistentes em toda a topologia global. Você pode usar configurações assimétricas para proxies que atendam às regiões primária e secundária, mas precisará ajustá-las após cada failover ou transição global.

  • Se o destino atender a vários proxies, o valor conjunto de MaxConnectionsPercent em todos esses proxies não deverá ultrapassar 100, para que o banco de dados não fique com excesso de assinaturas. Recomendamos usar um único proxy por destino para simplificar a configuração e o gerenciamento. Especificamente, você não precisa usar vários proxies por banco de dados para obter redundância. Para obter mais informações, consulte Usar vários proxies com um único destino.

Se você estiver usando a configuração MaxConnectionsPercent padrão ou um valor personalizado, mantenha pelo menos 30% de espaço livre entre o número de conexões permitidas e o número máximo esperado de conexões de clientes durante períodos de pico. Por exemplo:

  • Se você acredita que o proxy precisará de até 50% do limite de conexão configurado para o banco de dados, use uma configuração MaxConnectionsPercent de pelo menos 1.3 * 50% = 65%.

  • Ao usar a configuração MaxConnectionsPercent padrão de 100, verifique se o limite do banco de dados em si oferece espaço suficiente.

Esse espaço adicional melhora a experiência do cliente durante picos inesperados de workload e ajuda o RDS Proxy a redistribuir conexões em sua infraestrutura interna para gerenciamento de calor e outras finalidades.

Embora seja possível definir MaxConnectionsPercent com um valor mínimo de 1, recomendamos os seguintes valores mínimos com base no tipo de instância:

  • db.t3.small: 100

  • db.t3.medium: 55

  • db.t3.large: 35

  • db.r3.large ou superior: 20

MaxIdleConnectionsPercent

Valor mínimo Valor máximo Valor padrão (SQL Server) Valor padrão (outros mecanismos)
(zero) MaxConnectionsPercent 5% de MaxConnectionsPercent 50% de MaxConnectionsPercent

Para obter mais informações, consulte MaxIdleConnectionsPercent.

Essa configuração limita o número de conexões de banco de dados ociosas que o RDS Proxy mantém no grupo de conexões, como uma porcentagem do número máximo de conexões permitidas pelo banco de dados. Uma conexão de banco de dados (backend) é considerada ociosa quando não há atividade na conexão durante cinco minutos. Essa configuração se aplica a conexões entre o proxy e o banco de dados de backend.

Observe o seguinte:

  • Essa configuração limita o número de conexões ociosas no grupo, mas não força o proxy a reter um determinado número de conexões ociosas. Se a atividade do cliente for muito baixa, o número real de conexões do banco de dados de backend poderá ser menor que MaxIdleConnectionsPercent.

  • As conexões são consideradas ociosas quando estão disponíveis para reutilização no grupo de conexões do proxy. As conexões fixas não estão disponíveis para reutilização por outros clientes e, portanto, não são consideradas ociosas para fins de imposição de MaxIdleConnectionsPercent. Para ter mais informações sobe fixação, consulte Evitar a fixação de um RDS Proxy.

  • O número de conexões ociosas relatado pelos metadados do banco de dados geralmente é maior que o número de conexões ociosas registradas pelas métricas do RDS Proxy. Isso pode ocorrer devido a conexões diretas de clientes que ignoram o proxy, bem como a conexões internas usadas pela automação do Amazon RDS e do Aurora.

nota

O tempo de inatividade da conexão observado e aplicado na camada do proxy pode ser diferente do tempo ocioso relatado pelas ferramentas de banco de dados, como a lista de processos do MySQL ou as tabelas de estatísticas de atividades no PostgreSQL. Ocasionalmente, o RDS Proxy executa ping em conexões de backend, o que redefine os temporizadores de ociosidade do banco de dados, mesmo que a conexão permaneça ociosa em termos de atividade do cliente.

Práticas recomendadas:

A configuração padrão de 50 é adequada e recomendada para a maioria das workloads. A alteração da configuração tem o seguinte efeito:

  • Por um lado, quando você aumenta MaxIdleConnectionsPercent, o banco de dados observa um número maior de conexões ociosas, o que pode aumentar o consumo de recursos do banco de dados fora dos horários de pico. Por outro lado, os picos de conexão gerenciados por meio do proxy diminuem a latência de empréstimo porque há mais conexões prontamente disponíveis no grupo.

  • Quando você diminui MaxIdleConnectionsPercent, o proxy encerra conexões ociosas de forma mais incisiva, possivelmente reduzindo a contenção e o consumo de recursos provocados por essas conexões. No entanto, picos de conexão que passam pelo proxy podem causar tempos de empréstimo mais longos. Como há menos conexões disponíveis no grupo, o proxy precisa gastar um tempo maior para abrir novas conexões de backend durante um pico.

O consumo de recursos por conexões ociosas talvez não seja uma preocupação importante em bancos de dados que usam instâncias provisionadas, mas os bancos de dados do Aurora que usam o tipo de instância Sem Servidor v2 podem preferir otimizar o consumo de recursos ociosos para reduzir os custos.

IdleClientTimeout

Valor mínimo Valor máximo Valor padrão
1 minuto 8 horas 30 minutos

Para obter mais informações, consulte IdleClientTimeout.

Essa configuração determina por quanto tempo uma conexão de cliente pode permanecer ociosa até que o proxy a encerre. Observe que o RDS Proxy impõe uma vida útil máxima de conexão de 24 horas, independentemente de a conexão estar ociosa. Por exemplo, se você configurar IdleClientTimeout com 30 minutos (padrão) e executar ping no banco de dados a cada minuto, a conexão nunca excederá o tempo-limite de inatividade, mas não permanecerá aberta indefinidamente. O RDS Proxy encerra a conexão após 24 horas, mesmo que ela não seja considerada ociosa.

A configuração IdleClientTimeout se aplica à conexão entre um cliente (aplicações ou usuários interativos) e o RDS Proxy. Para entender o comportamento ocioso das conexões de backend entre o RDS Proxy e o banco de dados, consulte MaxIdleConnectionsPercent.

Práticas recomendadas:

  • O tempo-limite de inatividade deve ser longo o suficiente para permitir pausas normais na atividade do SQL dentro de uma conexão ou transação do cliente. Ele não deve ser tão longo a ponto de permitir que um cliente retenha recursos dos quais plausivelmente não precise mais, mas dos quais outros clientes possam precisar. Isso é particularmente importante em casos de fixação de conexão, pois uma conexão fixada por um cliente não pode ser reutilizada por outros clientes.

  • Para que o RDS Proxy aplique corretamente o tempo-limite, a conexão do cliente deve estar realmente ociosa, sem enviar nenhuma consulta (até mesmo verificações de integridade simples, como SELECT 1;) ou pings de protocolo (como COM_PING, no MySQL). Se você observar que as conexões não estão sendo encerradas apesar de excederem o tempo-limite, verifique a lógica de conexão dos drivers da aplicação. É particularmente provável que os grupos de conexões em nível de aplicação realizem suas próprias verificações de liveness, interferindo em IdleClientTimeout.

ConnectionBorrowTimeout

Valor mínimo Valor máximo Valor padrão
(zero) 5 minutos 2 minutos

Para obter mais informações, consulte ConnectionBorrowTimeout.

Quando um cliente se conecta ao RDS Proxy, o proxy precisa tomar emprestada uma conexão disponível no grupo ou abrir uma nova conexão de banco de dados. Essa configuração define por quanto tempo o RDS Proxy deve esperar que uma conexão seja tomada emprestada ou aberta para só então exibir um erro.

Observe o seguinte:

  • Um ConnectionBorrowTimeout de zero resulta em erros de tempo-limite quando o grupo de conexões ainda não contém uma conexão disponível. Isso se aplica mesmo que o grupo esteja abaixo da capacidade máxima e possa abrir uma nova conexão de backend.

  • Mesmo com MaxIdleConnectionsPercent igual a MaxConnectionsPercent, o número real de conexões no grupo pode ser menor que o máximo configurado. Em outras palavras, MaxIdleConnectionsPercent limita a quantidade de conexões ociosas, mas não força as conexões a permanecerem abertas.

É normal que um grupo de conexões funcione abaixo da capacidade máxima. Nessa situação, usar uma configuração ConnectionBorrowTimeout de zero pode impedir que o grupo cresça porque o grupo não pode esperar pela abertura de uma nova conexão. Por isso, é necessário usar valores de ConnectionBorrowTimeout diferentes de zero para todas as workloads, a menos que você prefira o comportamento descrito anteriormente.

nota

Essa configuração também se aplica quando o banco de dados não está pronto para aceitar conexões, como durante operações de manutenção off-line e failovers. A lógica para impor ConnectionBorrowTimeout é a mesma, independentemente de o banco de dados estar ativo ou inativo.

Consultas de inicialização e filtros de fixação

O RDS Proxy permite recursos adicionais que podem reduzir a fixação de conexão e, desse modo, melhorar a eficiência da multiplexação.

Uma consulta de inicialização consiste em uma ou mais instruções executadas sempre que o proxy configura uma nova conexão de banco de dados de backend. Se seus clientes usarem instruções idênticas para configurar parâmetros de sessão, você poderá mover essas instruções para a consulta de inicialização do proxy. Isso ajuda a reduzir a probabilidade de fixação e também melhora a eficiência: uma conexão de banco de dados de backend específica executa a respectiva consulta de inicialização uma vez durante a configuração, mas pode ser reutilizada posteriormente por muitos clientes. Lembre-se de que colocar instruções SQL na consulta de inicialização não as remove do tráfego do cliente. Você precisará remover essas instruções do código da aplicação para que elas não interfiram na multiplexação.

Os filtros de fixação de sessão são uma propriedade de configuração que impede que o proxy fixe determinados estados de sessão. A única opção de filtro disponível no momento, EXCLUDE_VARIABLE_SETS, instrui o proxy a ignorar todas as instruções SET ao determinar se uma sessão deve ser fixada. As instruções SET ainda assim são transmitidas ao banco de dados e podem afetar o estado da sessão, o que significa que essa opção somente é segura nas seguintes situações:

  1. As instruções SET não são operacionais, como definir uma variável do sistema com um valor idêntico ao padrão do servidor.

  2. As instruções SET e as consultas subsequentes fazem parte da mesma transação, e cada transação configura seu próprio estado de forma totalmente independente, para que não seja afetada pelas variáveis definidas por outras transações.

nota

O filtro de fixação EXCLUDE_VARIABLE_SETS é uma configuração do tipo tudo ou nada e não é possível escolher seletivamente quais instruções SET ignorar. Não use esse filtro como uma solução genérica para fixação, a menos que seu caso de uso se enquadre em uma das categorias discutidas na lista anterior.

Para obter melhores resultados, remova instruções desnecessárias do código da aplicação sempre que possível e use filtros somente se não for possível realizar modificações na aplicação. Isso promove um ambiente cliente-servidor menos turbulento e mais previsível, diferentemente de aplicar tratamento especial a instruções que, antes de mais nada, não são necessárias.

Importante

Nem as consultas de inicialização nem os filtros de fixação fazem com que o RDS Proxy altere o tráfego de consulta cliente-servidor. As instruções que chegam dos clientes continuam sendo transmitidas ao banco de dados, independentemente da consulta inicial ou da configuração do filtro de fixação.

Para obter mais informações, consulte:

Para conexões do PostgreSQL, também é possível colocar parâmetros de conexão compatíveis na mensagem de inicialização trocada entre o driver do cliente e o proxy. Isso evita o envio de comandos SET separados, reduzindo idas e voltas e evitando a fixação de conexão causada por instruções SET explícitas. Para obter mais informações, consulte Considerações sobre como se conectar ao PostgreSQL.

Alinhar a configuração de aplicações, proxies e bancos de dados

Conforme discutido na seção anterior, o RDS Proxy permite uma variedade de parâmetros para ajudar a alinhar o comportamento do proxy às necessidades da aplicação. No entanto, escolher os valores de configuração corretos é uma tarefa que abrange todas as camadas da pilha: a aplicação, o proxy e o próprio banco de dados. As configurações de todos esses componentes devem estar alinhadas, tendo os seguintes objetivos em mente:

  1. Ofereça o nível esperado de desempenho e escalabilidade durante operações normais.

  2. Favoreça a clareza e facilite a solução de problemas quando houver problemas na workload.

  3. Ajude a pilha a lidar com eventos inesperados (como picos de workload) com impacto mínimo na aplicação.

Ao escolher e ajustar as configurações em um ambiente de várias camadas, tente alinhar os valores de configuração de forma que os limites e os tempos-limite em uma camada inferior sejam iguais ou superiores aos limites e tempos-limite correspondentes em uma camada superior. Em outras palavras, trate as configurações de uma camada como um envelope que se encaixa no próximo envelope de configuração mais abaixo na pilha.

Por exemplo, suponha que sua aplicação seja a camada superior, o proxy seja a camada intermediária e o banco de dados seja a camada inferior. Se os tempos-limite e os limites do proxy forem menores que os limites da aplicação, os limites do proxy prevalecerão sobre os limites da aplicação. A aplicação não consegue usar suas próprias configurações e experimenta comportamentos que não podem ser explicados pela respectiva configuração.

Considere a configuração de proxy IdleClientTimeout como exemplo. Se os drivers da aplicação ou grupos de clientes impuserem seus próprios tempos-limite de inatividade, o tempo-limite de inatividade do proxy será uma proteção complementar às configurações da aplicação. Isso significa que IdleClientTimeout deve ser pelo menos igual a qualquer tempo-limite de inatividade no nível da aplicação para evitar confusão:

  • Quando o tempo-limite de inatividade da aplicação é menor que o tempo-limite do proxy, espera-se que a aplicação encerre as respectivas conexões conforme configurado. Se a aplicação não encerrar as conexões ociosas em tempo hábil, o proxy atuará como uma barreira.

  • Quando o tempo-limite de inatividade da aplicação é maior que o tempo-limite do proxy, a aplicação pode sofrer encerramentos de conexão considerados prematuros. Isso pode causar confusão do lado da aplicação.

A mesma lógica se aplica a outras configurações, como limites de conexão: as configurações de cada camada devem se encaixar no envelope definido pela configuração da próxima camada.

Para obter melhores resultados, as configurações devem incluir alguma folga entre uma camada e a seguinte. Por exemplo, você pode aumentar o tempo-limite do proxy em alguns segundos acima do tempo-limite da aplicação para evitar erros esporádicos devido ao descompasso de relógio do cliente/servidor ou caso o cliente precise de um tempo maior para encerrar a conexão normalmente.

Em outras palavras, alinhe suas configurações desta forma:

client timeout < proxy timeout < database timeout

Em vez de fazer isto:

client timeout = proxy timeout = database timeout

E evite isto:

client timeout > proxy timeout > database timeout

Configuração do banco de dados

Limites de conexão

O RDS Proxy usa a configuração MaxConnectionsPercent para determinar o tamanho máximo do grupo de conexões, o que significa que o tamanho do grupo de conexões do proxy depende do limite de conexão do banco de dados. Quando o limite de conexão do banco de dados é alterado, o tamanho do grupo do proxy acompanha automaticamente. Se quiser que o banco de dados reserve uma parte do limite de conexão para usuários não proxy, você deve fazer isso diminuindo a configuração MaxConnectionsPercent no proxy em vez de aumentar o limite do banco de dados.

O RDS Proxy não elimina a necessidade de configurar adequadamente os limites de conexão do banco de dados. Uma única conexão de proxy não é inerentemente mais leve que uma única conexão direta de cliente; portanto, não aumente os limites do banco de dados apenas porque você está usando um proxy. Um proxy não reduz a quantidade de trabalho que o banco de dados deve realizar para lidar com consultas, mas ajuda o banco de dados a lidar com a mesma workload usando menos conexões.

Tempos-limite de inatividade

Os bancos de dados podem impor seus próprios tempos-limite de inatividade; por exemplo, usando as configurações wait_timeout e interactive_timeout no MySQL ou as configurações transaction_timeout e idle_in_transaction_session_timeout no PostgreSQL. É improvável que os valores padrão dessas configurações interfiram na configuração do proxy, mas se você usar tempos-limite personalizados no nível do banco de dados, eles devem ser pelo menos tão longos quanto os tempos-limite correspondentes do proxy. Do contrário, haverá erros de conexão no proxy devido a tempos-limite prematuros.

A mesma lógica se aplica aos ambientes de banco de dados que usam finalizadores de conexão, que são scripts ou processos que monitoram o estado da sessão e encerram ativamente as conexões com base em determinados critérios. Se seu ambiente usa essas técnicas, a lógica de encerramento de conexão deve estar alinhada com as configurações do proxy.

Os bancos de dados que lidam com toda a workload por meio do proxy geralmente podem depender da configuração do proxy para tempos-limite de inatividade e deixar as configurações no nível do banco de dados com os valores padrão.

Configuração da aplicação

Gerenciar estados de sessão

Muitos drivers de banco de dados, frameworks de aplicação e ferramentas de mapeamento objeto-relacional (ORM) usam variáveis de sessão ou instruções SET para configurar conexões antes de enviar tráfego de consulta. O uso de instruções de inicialização de conexão e transação pode não ser óbvio quando se analisa apenas o código da aplicação, e pode haver várias camadas de abstração entre o banco de dados em si e as instruções SQL e a lógica da aplicação. Você pode usar o recurso de registro em log aprimorado do RDS Proxy para registrar os motivos de fixação de conexão, e os logs de consulta do banco de dados podem fornecer mais informações sobre todas as instruções enviadas pelas conexões do banco de dados.

Considere as seguintes práticas recomendadas:

  1. Defina os parâmetros de conexão somente quando eles forem diferentes dos padrões do banco de dados e a sessão do cliente precisar se desviar desses padrões. A remoção de instruções de inicialização desnecessárias não somente ajuda na multiplexação, mas também reduz o número de idas e voltas entre cliente e servidor para cada nova conexão de banco de dados.

  2. Defina variáveis e definições de configuração de forma consistente em todas as conexões.

  3. Evite a configuração de sessão que também possa ser aplicada no runtime da consulta. Por exemplo, se clientes diferentes precisarem ver dados em fusos horários diferentes, considere usar funções de conversão de fuso horário em nível de consulta em vez de definir o fuso horário em nível de sessão.

  4. Se possível, mova as instruções de configuração da sessão para a camada proxy usando o recurso de consulta de inicialização. Para obter mais detalhes, consulte Consultas de inicialização e filtros de fixação.

Verificações de liveness

Se sua aplicação usa agrupamento de conexões ou drivers avançados, procure configurações relacionadas a verificações de liveness, como pings de protocolo, instruções de verificação de integridade ou consultas de keep-alive. O RDS Proxy trata todas as solicitações do cliente da mesma forma, portanto, mesmo que uma consulta SELECT 1; ou solicitação COM_PING seja autônoma do ponto de vista de aplicação, ela impede que o proxy imponha tempos-limite de clientes ociosos e gerencie o tamanho do grupo de conexões de acordo com MaxIdleConnectionsPercent.

nota

O RDS Proxy impõe uma vida útil máxima de conexão de 24 horas, independentemente da atividade da conexão.

Na maioria dos casos, pode ser apropriado desabilitar as verificações de liveness do lado do cliente para reduzir o ruído do protocolo e ajudar o RDS Proxy a gerenciar conexões ociosas. Existem casos extremos em que talvez você deva executar essas verificações de integridade independentemente:

  • De desejar deliberadamente evitar que determinadas conexões atinjam o tempo-limite na camada proxy.

  • De desejar permitir que o driver da aplicação ou o grupo detecte de maneira proativa quando uma conexão é interrompida pelo proxy. Por exemplo, as conexões fixas de backend podem ser encerradas devido à reinicialização do banco de dados e as conexões de clientes podem ultrapassar a vida útil máxima de 24 horas.

Considere a possibilidade de desabilitar as verificações de liveness do lado da aplicação ou executá-las apenas para as conexões específicas que você deseja evitar que atinjam o tempo-limite.

Acompanhamento dos estados de sessão

Alguns drivers de banco de dados do MySQL, como o driver do MariaDB, usam variáveis session_track_* para permitir o rastreamento de estados de sessão. Com esse recurso habilitado, sempre que o cliente faz uma alteração no estado da sessão que o servidor consegue rastrear, o servidor inclui as informações de mudança de estado nos respectivos pacotes de resposta. Isso permite que o driver seja avisado sobre o estado da sessão pelo servidor.

Essa forma de rastreamento de estado de sessão pode ser significativa quando o cliente interage diretamente com o servidor e implementa seus próprios recursos de gerenciamento de sessão, como a migração de sessão em ambientes com vários servidores. O RDS Proxy implementa seus próprios mecanismos de rastreamento de estado e não usa as informações habilitadas pelas variáveis session_track_*. No entanto, a definição dessas variáveis causa a fixação de sessão.

Se o driver do banco de dados definir essas variáveis, você poderá procurar maneiras de desabilitar a funcionalidade de rastreamento no driver, alternar para um driver diferente ou usar filtros de fixação de sessão para ignorar as instruções, se for seguro fazer isso. Para obter mais detalhes, consulte Consultas de inicialização e filtros de fixação.