Este tópico aborda as dúvidas e os problemas mais comuns sobre o uso do database proxy para RDS for MySQL.
Sumário
O database proxy utiliza o QPS ou TPS da instância primária?
O endpoint do database proxy é igual ao endpoint de uma instância comum?
O tipo de rede interna do database proxy é o mesmo da instância primária?
Qual arquitetura os database proxies utilizam? Há suporte a failover?
Qual é a relação entre a especificação do proxy e a especificação do nó de proxy?
Qual é a relação entre o número de nós de proxy e a especificação do proxy?
Existe uma relação entre o número de nós de proxy e o número de endpoints de proxy?
O desempenho de um database proxy melhora se eu adicionar mais endpoints de proxy?
Posso modificar um endpoint de database proxy (endpoint de divisão de leitura/escrita)?
Por que a carga em cada nó não corresponde aos pesos de leitura configurados?
Após ativar o database proxy, como verifico a divisão de leitura/escrita?
Posso alterar a zona de disponibilidade ao modificar a configuração do proxy?
O que é um database proxy?
O database proxy é um service de proxy de rede posicionado entre seus servidores de aplicação e de banco de dados. Ele encaminha todas as requisições da aplicação para o banco de dados e oferece recursos avançados, como divisão automática de leitura/escrita, divisão de transações, pools de conexões e persistência de conexões. Esse recurso foi projetado para garantir alta disponibilidade, alto desempenho e facilidade de uso e manutenção.
Qual é a diferença entre proxies de uso geral e dedicados?
Uso geral: Compartilha recursos físicos de CPU, o que torna essa opção econômica. A especificação máxima do proxy é de 16 núcleos de CPU (8 nós de proxy) e não há cobrança por esse tipo.
Dedicado: Utiliza recursos físicos exclusivos de CPU, proporcionando maior estabilidade de desempenho. A especificação máxima do proxy é de 64 núcleos de CPU (32 nós de proxy), com faturamento baseado no pagamento conforme o uso.
Para mais informações, consulte Proxies de uso geral e dedicados, Relação entre o número de nós de proxy e a especificação do proxy e Taxas do database proxy.
O database proxy utiliza o QPS ou TPS da instância primária?
Não.
O endpoint do database proxy é igual ao endpoint de uma instância comum?
Não.
Um endpoint de instância comum direciona todas as requisições para essa instância específica.
Já o endpoint do database proxy identifica automaticamente as requisições de leitura e escrita com base nas instruções SQL. Ele encaminha as requisições de escrita para a instância primária e as de leitura para as instâncias somente leitura. Esse processo permite a divisão de leitura/escrita e reduz a carga na instância primária.
Após ativar o database proxy, os endpoints originais das instâncias primária e somente leitura são removidos?
Não.
O tipo de rede interna do database proxy é o mesmo da instância primária?
A rede interna de um database proxy é sempre uma VPC.
Qual arquitetura os database proxies utilizam? Há suporte a failover?
O database proxy utiliza uma arquitetura de alta disponibilidade com dois nós primários. O tráfego é distribuído entre os dois nós na proporção de 1:1. Se um nó falhar, o outro assumirá todo o tráfego. Uma tarefa é acionada automaticamente para reconstruir o nó com falha e manter a alta disponibilidade.
Para mais detalhes sobre a arquitetura de implantação, consulte Arquitetura de implantação do proxy.
Relação entre especificações de proxy e de nó
proxy specification = Sum of all proxy node specifications
Por exemplo, suponha que um proxy dedicado esteja implantado em duas zonas (Zona de Disponibilidade A e Zona de Disponibilidade B). Na Zona de Disponibilidade A, existem dois nós de proxy, cada um com especificação de 1 núcleo de CPU. Na Zona de Disponibilidade B, também há dois nós de proxy, mas com especificação de 2 núcleos de CPU cada. A especificação total do proxy é calculada da seguinte forma: (1 núcleo de CPU × 2) + (2 núcleos de CPU × 2) = 2 núcleos de CPU + 4 núcleos de CPU = 6 núcleos de CPU.
Relação entre nós de proxy e especificação
number of proxy nodes = proxy specification / Specification per Unit, where the specification per unit is fixed at 2 CPU cores.
Por exemplo, se a especificação do proxy for de 6 núcleos de CPU, o número de nós de proxy será 3 (6 / 2).
Limites de especificação de nó de proxy
A especificação de um único nó de proxy varia de 1 a 8 núcleos de CPU para o tipo de uso geral e de 1 a 16 núcleos de CPU para o tipo dedicado.
Todos os nós de proxy dentro da mesma zona de disponibilidade devem ter a mesma especificação.
Em uma implantação em zona dupla com dois nós, ambos devem possuir a mesma especificação.
Nós de proxy em zonas de disponibilidade diferentes podem ter especificações distintas. Para proxies de uso geral, recomendamos que os nós em zonas diferentes utilizem a mesma especificação.
Relação entre nós de proxy e endpoints
Não.
Após ativar o database proxy para uma instância RDS, crie de um a sete endpoints de proxy. Para cada endpoint de proxy, é possível criar um endpoint interno e um endpoint público. Para mais informações, consulte Adicionar um endpoint de proxy.
Adicionar endpoints de proxy melhora o desempenho?
Não.
O desempenho de um database proxy depende do número de instâncias somente leitura e da quantidade de nós de proxy (especificação do proxy) nas instâncias RDS High-availability Edition. Nas instâncias RDS Cluster Edition, o desempenho varia conforme o número de instâncias secundárias e a quantidade de nós de proxy (especificação do proxy).
Aumentar o número de instâncias somente leitura (para High-availability Edition) ou de instâncias secundárias (para Cluster Edition) eleva a capacidade de processamento de leitura do database proxy.
Incrementar a quantidade de nós de proxy (especificação do proxy) aprimora o desempenho geral do database proxy.
Limites de conexão do database proxy
O database proxy não impõe limite máximo de conexões. As especificações dos nós de computação do seu banco de dados determinam esse limite.
Como tratar erros de tempo limite de conexão
Aumente o valor do parâmetro wait_timeout e tente conectar novamente. Para saber como modificar parâmetros da instância, consulte Definir os parâmetros de uma instância do ApsaraDB RDS for MySQL.
Modificação de endpoint de proxy
Sim.
Modifique o endpoint do database proxy (endpoint de divisão de leitura/escrita) conforme necessário. Para mais detalhes, consulte Modificar um endpoint de proxy.
Envio de requisições de leitura para a instância primária
Sim.
Ao configurar a distribuição de pesos de leitura, atribua um peso de leitura à instância primária. Para saber como realizar essa atribuição, consulte Ativar o recurso de database proxy para uma instância do ApsaraDB RDS for MySQL.
Suporte a hints para divisão de leitura/escrita
Sim. Utilize um hint para forçar a execução de uma requisição na instância primária. Para conhecer os formatos de hint compatíveis com a divisão de leitura/escrita do RDS, consulte a seção "Use a hint to specify whether to send an SQL statement to a primary or read-only instance" em Regras padrão de alocação de peso de leitura.
Pesos de leitura modificados não entram em vigor
Após a modificação dos pesos de leitura, apenas as novas conexões seguem a nova distribuição. As conexões já estabelecidas permanecem inalteradas.
Desequilíbrio de carga com pesos de leitura
Caso a distribuição de carga entre os nós não corresponda aos pesos de leitura configurados, verifique os seguintes pontos:
Confira se as requisições fazem parte de uma transação. Todas as requisições dentro de uma transação são roteadas para a instância primária. Ative o divisão de transações para reduzir a carga na instância primária.
Certifique-se de que a conexão ocorre exclusivamente por meio de um endpoint de database proxy. Conexões feitas pelos endpoints da instância primária ou somente leitura ignoram a distribuição de pesos de leitura.
Configuração de pesos de leitura sem database proxy
Com o database proxy desativado, não é possível configurar pesos de leitura para instâncias somente leitura. No entanto, ainda é viável obter divisão de leitura/escrita e balanceamento de carga utilizando endpoints separados para as instâncias primária e somente leitura no código da aplicação.
Failover de conexão para instâncias somente leitura indisponíveis
Não, as conexões existentes com a instância com falha não passam por failover automático. Uma nova conexão com uma instância saudável só é estabelecida após o tempo limite da conexão com falha expirar.
Como verificar a divisão de leitura/escrita após ativar o service de database proxy?
Consulte Verificar a divisão de leitura/escrita.
Sincronização automática de dados para novas instâncias somente leitura
Sim. Ao ativar o database proxy para divisão de leitura/escrita, os dados históricos são sincronizados automaticamente da instância primária para a instância somente leitura. Nenhuma intervenção manual é necessária.
Pool de conexões do proxy versus pool de conexões da aplicação
O database proxy oferece um pool de conexões no nível do proxy, independente do pool no nível do cliente da sua aplicação. Caso sua aplicação já utilize um pool de conexões, o uso do pool do proxy torna-se desnecessário. Para mais informações sobre o pool de conexões do database proxy, consulte Configurar um pool de conexões.
Tratamento de caracteres ilegíveis nos resultados de consulta
Execute o comando abaixo para verificar se os conjuntos de caracteres usados pela instância primária e pelas instâncias somente leitura são consistentes:
select
@@global.character_set_results,
@@global.character_set_client,
@@global.character_set_connection,
@@global.character_set_server;Se houver inconsistência nos conjuntos de caracteres, caracteres ilegíveis poderão aparecer. Modifique o conjunto de caracteres da instância primária ou de uma instância somente leitura para garantir a consistência. Para saber como alterar conjuntos de caracteres da instância, consulte Conjuntos de caracteres de instâncias do ApsaraDB RDS for MySQL.
Sincronização automática de DDL
Sim. Todas as operações DDL, como criação ou exclusão de bancos de dados e tabelas, alteração de estruturas de tabela e modificação de permissões, são sincronizadas automaticamente da instância primária para suas instâncias secundárias.
Visualização do ID da VPC e do vSwitch
Na página Database proxy da sua instância, acesse a seção Connection information. Para visualizar as informações, passe o ponteiro do mouse sobre o ícone à direita de Port, conforme ilustrado na figura a seguir.
Impacto da migração entre zonas na instância primária
A migração de nós de proxy entre zonas de disponibilidade afeta apenas cargas de trabalho que utilizam um endpoint de database proxy. Conexões realizadas pelo endpoint da instância primária, endpoint de instância somente leitura, endpoint de leitura/escrita do cluster, endpoint somente leitura do cluster ou endpoint no nível do nó não sofrem impacto. Para minimizar efeitos, alterne suas cargas de trabalho para um endpoint não afetado e execute a migração fora do horário de pico.
Impacto da migração de proxy entre zonas
Ao migrar um proxy entre zonas de disponibilidade, as conexões que utilizam o database proxy podem sofrer uma desconexão transitória de aproximadamente 30 segundos. A duração real do impacto depende da sua carga de trabalho. Para reduzir efeitos, alterne suas cargas de trabalho para um endpoint não afetado e realize a migração fora do horário de pico. Para mais informações, consulte Migrar database proxies entre zonas.
Impacto da migração entre zonas no acesso mais próximo
O acesso pode ficar indisponível.
A migração entre zonas pode invalidar a configuração de acesso mais próximo. Após a migração, a nova zona torna-se acessível por padrão; a zona original deixa de ser acessível. Se a zona do endpoint de proxy diferir da nova zona padrão, o acesso mais próximo a essa zona falhará.
| Cenário | Zona original do nó de proxy | Endpoint de proxy | Acesso mais próximo original | Nova zona do nó de proxy | Nova zona padrão | Nova zona do endpoint de proxy | Novo acesso mais próximo |
|---|---|---|---|---|---|---|---|
Cenário 1: Zone A+Zone B → Zone A+Zone C |
Zone A | Proxy endpoint a | Zone A | Zone A | Zone A | Zone A | Zone A |
| Zone C | Inválido | ||||||
| Zone B | Proxy endpoint b | Zone B | Zone C | Zone C | Zone C | Zone C | |
| Zone D | Inválido | ||||||
Cenário 2: Zone A+Zone B → Zone C+Zone D |
Zone A | Proxy endpoint a | Zone A | Zone C | Zone C | Zone C | Zone C |
| Zone E | Inválido | ||||||
| Zone B | Proxy endpoint b | Zone B | Zone D | Zone D | Zone D | Zone D | |
| Zone E | Inválido |
Alteração da zona de disponibilidade durante a configuração
Não.
Caso precise migrar para outra zona de disponibilidade, consulte Migrar database proxies entre zonas.
Resolução de erro de vSwitchId em implantação de zona única
Ao mudar de uma implantação em zona dupla (por exemplo, Zona de Disponibilidade 1 e Zona de Disponibilidade 2) para uma implantação de zona única (por exemplo, Zona de Disponibilidade 1), exclua primeiro o endpoint do database proxy na Zona de Disponibilidade 2. Para mais informações, consulte Modificar um endpoint de proxy.
Os endereços IP resolvidos do proxy são fixos?
Não. Sempre utilize o endpoint do database proxy (por exemplo, d3pswqe3jk9xwc5d****-rw4rm.rwlb.rds.aliyuncs.com) para se conectar, e não o endereço IP resolvido.
Verificação de conexões via endpoint de proxy
Identifique o método de conexão pelo ID da sessão. Um ID de sessão menor que 16777215 indica uma conexão por meio de um endpoint de instância. Um ID superior indica uma conexão via endpoint de database proxy.
Os IDs de sessão ficam visíveis em Gerenciamento de sessões.
Dados não visíveis imediatamente após escritas
Causa comum: Isso ocorre quando o proxy roteia sua requisição de leitura para uma instância somente leitura que está atrasada em relação à instância primária devido ao atraso de replicação.
Soluções:
Usar um hint: Para consultas que exigem forte consistência de leitura, utilize o hint
/*FORCE_MASTER*/para rotear a requisição à instância primária.Desativar a divisão de transações e encapsule as consultas que exigem forte consistência de leitura dentro de uma transação.
Definir o nível de consistência para consistência global.
Cada uma dessas soluções roteia mais consultas para a instância primária, o que pode aumentar sua carga. Avalie a capacidade da instância primária antes de aplicar alterações. Recomendamos o uso de hints como método preferencial para rotear apenas requisições específicas de leitura de alta consistência para a instância primária.