O proxy de banco de dados do ApsaraDB RDS for MySQL é um service de proxy de rede entre seu banco de dados e sua aplicação. O proxy processa todas as solicitações enviadas pela aplicação ao banco de dados e simplifica o gerenciamento de conexões para instâncias do RDS MySQL.
Use o recurso de proxy de banco de dados do ApsaraDB RDS for MySQL quando sua instância primária estiver sob alta carga ou quando for necessária proteção contra interrupções durante operações de O&M, como switchovers. A divisão de leitura e escrita (read/write splitting) proporciona balanceamento de carga para o tráfego do service e reduz a carga de CPU na instância primária. As conexões persistentes (proteção contra interrupções) mantêm ativas as conexões entre sua aplicação e o proxy, enquanto a criptografia Secure Sockets Layer (SSL) protege a transmissão de dados. Esses recursos melhoram a disponibilidade e a segurança da instância.
Cenários
O proxy de banco de dados do ApsaraDB RDS for MySQL é aplicável aos seguintes cenários:
Cargas de trabalho com necessidade de divisão de leitura e escrita (read/write splitting).
Situações que exigem proteção contra interrupções durante operações de O&M, como switchovers, ou em caso de falha.
Contextos em que a instância primária está sob alta carga (grande volume de solicitações em uma transação ou excesso de conexões).
Cargas de trabalho baseadas principalmente em conexões de curta duração.
Casos de uso que demandam acesso ao nó mais próximo para reduzir a latência.
Cargas de trabalho puramente de leitura e aquelas que exigem isolamento.
Por exemplo, ao comprar uma instância do RDS composta por uma instância primária e quatro instâncias somente leitura, e desejar conectar tanto a Aplicação A (puramente de leitura) quanto a Aplicação B (leitura e escrita) à instância, é possível agrupar a instância somente leitura 1 e a instância somente leitura 2 no endpoint de proxy A (modo Read-only) para a Aplicação A. Além disso, agrupe a instância primária, a instância somente leitura 3 e a instância somente leitura 4 no endpoint de proxy B (modo Read/Write) para a Aplicação B. Assim, as duas cargas de trabalho ficam fisicamente isoladas em seu uso do banco de dados e não se afetam mutuamente.
Termos
Endpoint de proxy (anteriormente terminal de proxy)
O endpoint de proxy é o núcleo do proxy de banco de dados. Suporta políticas de acesso personalizadas, permitindo a alteração do prefixo do endpoint e do número da porta. Conecte-se à instância do RDS por meio de um endpoint de proxy de banco de dados para usar os recursos avançados do proxy.
Ative o proxy de banco de dados. Em seguida, é possível solicitar um endpoint interno e um endpoint público para cada endpoint de proxy, além de personalizar a política de acesso de cada um para atender aos requisitos de cenários comuns e melhorar a flexibilidade do negócio. Para mais informações, consulte Configure access policies for a database proxy endpoint e Database connection.
Divisão de leitura e escrita (Read/write splitting)
Read/write splitting refere-se ao encaminhamento automático de solicitações de leitura e escrita por meio de um endpoint de proxy.
Aplicações com mais leituras do que escritas podem gerar alta pressão de leitura na instância primária e afetar seu negócio. A divisão de leitura e escrita encaminha automaticamente as solicitações de escrita para a instância primária e as de leitura para as instâncias somente leitura. Esse mecanismo permite a distribuição automática de solicitações e reduz a carga na instância primária.
Conexões persistentes
O recurso persistent connections do proxy do RDS MySQL mantém ativa a conexão entre a aplicação e o proxy durante operações como switchovers de instâncias. Aplicações que acessam o banco de dados por meio do endpoint de proxy não recebem erros de desconexão.
Divisão de transações
O proxy de banco de dados ativa a transaction splitting por padrão. Esse recurso encaminha as solicitações de leitura realizadas antes de uma operação de escrita dentro de uma transação para as instâncias somente leitura, reduzindo a carga na instância primária.
Pool de conexões
O connection pool feature resolve de forma eficaz a carga excessiva da instância causada por excesso de conexões ou por cargas de trabalho baseadas em conexões de curta duração (como PHP) que estabelecem novas conexões com frequência.
Zona
A zona é onde residem os nós de proxy e o endpoint de proxy. Ative o proxy de banco de dados. Em seguida, há suporte para Migrate proxy nodes across zones.
Acesso ao nó mais próximo
Quando o proxy de banco de dados usa uma implantação multizona, ative o nearest access feature. Esse recurso permite conectar uma aplicação específica a um nó de proxy na mesma zona, para que a aplicação, o nó de proxy e o nó somente leitura residam na mesma zona, minimizando a latência.
Criptografia SSL
Aplique a SSL encryption ao endpoint do proxy de banco de dados para garantir que os dados sejam transmitidos com segurança.
Arquitetura de implantação do proxy
O proxy de banco de dados do ApsaraDB RDS for MySQL suporta implantações em zona única e em zona dupla.
Implantação em zona única: Todos os nós de proxy residem na mesma zona.
Implantação em zona dupla: Os nós de proxy residem em duas zonas diferentes, oferecendo recuperação de desastres entre zonas sem custo adicional.
Modos de implantação
O proxy de banco de dados oferece três modos de implantação. Os modos diferem em relação ao número de zonas, ao total de nós de proxy, à consistência das especificações dos nós de proxy e aos tipos de proxy suportados.
O modo de implantação 3 aloca todos os nós de proxy em uma única zona, de modo que o proxy de banco de dados não pode fornecer service durante uma falha no nível da zona. Os modos de implantação 1 e 2 distribuem os nós de proxy em duas zonas e oferecem recuperação de desastres entre zonas.
Modo de implantação 1
Zonas: Duas zonas
Número total de nós de proxy: 4
Limites de especificação dos nós de proxy: Os nós de proxy na mesma zona devem usar a mesma especificação.
Tipos de proxy suportados: Dedicated. Mecanismo de recuperação de desastres:
Falha no nível do nó de proxy: O nó com falha para de processar o tráfego, encaminhando-o para os outros nós de proxy saudáveis na mesma zona.
-
Falha no nível da zona: O tráfego do service é encaminhado para os nós de proxy na zona saudável (recuperação de desastres entre zonas). Após a recuperação dos nós de proxy na zona com falha, o novo tráfego do service é direcionado para os nós recuperados, enquanto o roteamento das conexões persistentes existentes permanece inalterado até a expiração automática das conexões.
Ative o nearest access feature, disponível apenas no modo de implantação 1; o recurso pode ficar indisponível em caso de falha no nível da zona, pois a disponibilidade geral do proxy de banco de dados tem prioridade sobre a latência de acesso.
Modo de implantação 2
Zonas: Duas zonas
Número total de nós de proxy: 2
Limites de especificação dos nós de proxy: Os dois nós devem usar a mesma especificação.
Tipos de proxy suportados: Dedicated e General-purpose. Mecanismo de recuperação de desastres:
Como o proxy de banco de dados é implantado com dois nós em duas zonas, uma falha no nível do nó de proxy equivale a uma falha no nível da zona.
-
Quando ocorre uma falha, o tráfego do service é encaminhado para o nó de proxy na outra zona saudável.
Modo de implantação 3
Zonas: Zona única
Número total de nós de proxy: 2
Limites de especificação dos nós de proxy: Os nós de proxy na mesma zona devem usar a mesma especificação.
Tipos de proxy suportados: Dedicated e General-purpose. Mecanismo de recuperação de desastres:
Falha no nível do nó de proxy: O nó com falha para de processar o tráfego, e todo o tráfego do service é processado pelo outro nó de proxy saudável na mesma zona.
-
Falha no nível da zona: O proxy de banco de dados não pode fornecer service. Aguarde a recuperação da falha no data center da zona ou modifique manualmente o proxy para um modo de implantação entre zonas.
Ative o proxy de banco de dados. Em seguida, modifique a arquitetura de implantação do proxy. Para mais informações, consulte Modify proxy configuration.
Modo de implantação padrão e zonas de proxy
Mantenha a mesma zona para o proxy de banco de dados, o endpoint de proxy e a instância do RDS a fim de reduzir a latência de rede causada pelo acesso entre zonas.
Selecione um plano de implantação de zona e um tipo de proxy para a instância. Após isso, o modo de implantação de proxy padrão e as zonas de proxy padrão são definidos da seguinte forma:
|
Plano de implantação de zona da instância |
Tipo de proxy |
Modo de implantação de proxy padrão |
Zonas de proxy padrão |
|
Implantação em zona única |
Dedicated |
Modo de implantação 3 |
Por padrão, a mesma zona primária do nó primário da instância do RDS. |
|
Implantação em zona única |
General-purpose |
Modo de implantação 3 |
Por padrão, a mesma zona primária do nó primário da instância do RDS. |
|
Implantação em zona dupla |
Dedicated |
Modo de implantação 1 |
Zona 1: Por padrão, a mesma zona do nó primário da instância. Zona 2: Por padrão, a mesma zona do nó secundário da instância. |
|
Implantação em zona dupla |
General-purpose |
Modo de implantação 2 |
Zona 1: Por padrão, a mesma zona do nó primário da instância. Zona 2: Por padrão, a mesma zona do nó secundário da instância. |
Tipos de proxy
O proxy de banco de dados do ApsaraDB RDS for MySQL oferece dois tipos de proxy: General-purpose e Dedicated.
General-purpose: Os recursos físicos de CPU são compartilhados. Esse tipo é gratuito e mais econômico.
Dedicated: Os recursos físicos de CPU são de uso exclusivo. Esse tipo usa o método de faturamento pagamento conforme o uso e oferece melhor estabilidade de desempenho. A tabela a seguir descreve as diferenças entre os dois tipos de proxy e os recursos suportados por cada tipo:
|
Item |
General-purpose |
Dedicated |
|
Método de faturamento |
Gratuito |
Pagamento conforme o uso. Para mais informações, consulte Billing. |
|
Tipo de recurso |
Recursos físicos de CPU compartilhados |
Recursos físicos de CPU de uso exclusivo, com melhor estabilidade de desempenho. |
|
Faixa de especificação de um único nó de proxy |
1 a 8 núcleos |
1 a 16 núcleos |
|
Instâncias do RDS MySQL suportadas |
Instâncias da série de alta disponibilidade e Cluster Edition do RDS MySQL |
|
|
Arquitetura de implantação |
Modos de implantação 2 e 3 |
Modos de implantação 1, 2 e 3 |
|
Acesso ao nó mais próximo |
Não suportado |
Suportado |
|
Divisão de leitura e escrita |
Suportado |
|
|
Divisão de transações |
Suportado |
|
|
Endpoints de proxy |
Uma única instância do RDS MySQL suporta de 1 a 7 endpoints de proxy. Cada endpoint de proxy suporta um endpoint interno e um endpoint público. |
|
|
Conexões persistentes durante switchovers |
Suportado |
Suportado |
|
Conexões persistentes durante failovers |
Não suportado |
Suportado |
|
Pool de conexões |
Suportado |
|
|
Criptografia SSL |
Suportado |
Na tabela anterior, uma célula vazia na coluna Dedicated indica que o valor é o mesmo da coluna General-purpose.
A especificação do proxy e o número de proxies são calculados da seguinte forma:
-
Relação entre a especificação do proxy e a especificação de um único nó de proxy:
Proxy specification = the sum of the specifications of all proxy nodes.Por exemplo, considere um proxy Dedicated implantado em duas zonas (Zona A + Zona B). A especificação de CPU de um único nó de proxy na Zona A é de 1 núcleo, com 2 nós. A especificação de CPU de um único nó de proxy na Zona B é de 2 núcleos, com 2 nós. Assim,
proxy specification = the proxy specification of Zone A + the proxy specification of Zone B = 1 core x 2 + 2 cores x 2 = 2 cores + 4 cores = 6 cores. -
Relação entre o número de proxies e a especificação do proxy:
Number of proxies = proxy specification / unit proxy specification. A especificação unitária do proxy é fixa em 2 núcleos de CPU.Por exemplo, se a especificação do proxy de uma instância de proxy for de 6 núcleos,
number of proxies = 6 cores / 2 cores = 3.
Notas de uso
Para mais informações, consulte Usage notes for the database proxy feature.
Faturamento
Para mais informações, consulte Billing of database proxies.
Uso
Para mais informações, consulte Use database proxy.