Gerenciamento de conexões do Amazon Aurora
O Amazon Aurora normalmente envolve um cluster de instâncias de banco de dados, em vez de uma única instância. Cada conexão é processada por uma instância de banco de dados específica. Quando você se conecta a um cluster do Aurora, o nome do host e a porta especificados apontam para um processador intermediário chamado endpoint. O Aurora usa o mecanismo de endpoint para abstrair essas conexões. Por isso, você não precisa codificar todos os nomes de host ou escrever a própria lógica para balancear a carga e reorganizar conexões quando algumas instâncias de banco de dados não estão disponíveis.
Em determinadas tarefas do Aurora, as instâncias ou os grupos diferentes de instâncias realizam funções diferentes. Por exemplo, a instância primária processa todas as instruções Data Definition Language (DDL) e Data Manipulation Language (DML). Até 15 réplicas do Aurora processam tráfego de consulta somente leitura.
Usando endpoints, mapeie todas as conexões para a instância apropriada ou o grupo de instâncias baseado no caso de uso. Por exemplo, para realizar instruções DDL, conecte-se à instância que seja a primária. Para realizar consultas, conecte-se ao endpoint leitor, com o Aurora realizando automaticamente o balanceamento de carga entre todas as réplicas do Aurora. Em clusters com instâncias de banco de dados de capacidades ou configurações diferentes, conecte-se a endpoints personalizados associados a subconjuntos diferentes de instâncias de banco de dados. Para diagnóstico ou ajuste, conecte-se a um endpoint de instância específico para examinar detalhes sobre uma instância de banco de dados específica.
Tópicos
- Tipos de endpoints do Aurora
- Visualizar os endpoints de um cluster do Aurora
- Usar o endpoint de cluster
- Usar o endpoint de leitor
- Usar endpoints personalizados
- Criar um endpoint personalizado
- Visualizar endpoints personalizados
- Editar um endpoint personalizado
- Excluir um endpoint personalizado
- Exemplo da AWS CLI de ponta a ponta para endpoints personalizados
- Usar os endpoints de instância
- Como os endpoints do Aurora funcionam com alta disponibilidade
Tipos de endpoints do Aurora
Um endpoint é representado como um URL específico do Aurora que contém um endereço de host e uma porta. Os tipos a seguir de endpoints estão disponíveis em um cluster de banco de dados do Aurora.
- Endpoint do cluster
-
Um endpoint de cluster (ou endpoint de gravador) de um cluster de banco de dados do Aurora se conecta à instância de banco de dados primária atual desse cluster de banco de dados. Esse endpoint é o único capaz de realizar operações de gravação como instruções DDL. Por isso, o endpoint cluster é o único que se conecta a quando você configura um cluster ou quando o cluster só contém uma única instância de banco de dados.
Cada cluster de banco de dados do Aurora tem um único endpoint cluster e uma única instância de banco de dados primária.
Use o endpoint cluster em todas as operações de gravação no cluster de banco de dados, inclusive inserções, atualizações, exclusões e alterações DDL. Você também pode usar o endpoint de cluster para operações de leitura, como consultas.
O endpoint de cluster dá suporte a failover para conexões de leitura/gravação para o cluster de banco de dados. Se a instância de banco de dados primária atual de um cluster de banco de dados falhar, o Aurora fará failover automático para uma nova instância de banco de dados primária. Durante um failover, o cluster de banco de dados continua atendendo a solicitações de conexão para o endpoint de cluster pela nova instância de banco de dados primária, com interrupção mínima de serviço.
O exemplo a seguir ilustra um endpoint de cluster de um cluster de banco de dados do Aurora MySQL.
mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306
- Endpoint de leitor
-
Um endpoint de leitor de um cluster de banco de dados do Aurora é compatível com o balanceamento de carga para conexões somente leitura com o cluster de banco de dados. Use o endpoint do leitor para operações de leitura, como consultas. Ao processar essas instruções nas réplicas somente leitura do Aurora, esse endpoint reduz a sobrecarga na instância primária. Ele também ajuda o cluster a dimensionar a capacidade de processar consultas
SELECT
simultâneas, proporcional ao número de réplicas do Aurora no cluster. Cada cluster de banco de dados do Aurora tem um único endpoint leitor.Se o cluster tiver uma ou mais réplicas do Aurora, o endpoint de leitor faz o balanceamento de carga de cada solicitação de conexão entre as réplicas do Aurora. Nesse caso, só é possível executar somente instruções somente leitura, como
SELECT
nessa sessão. Se o cluster tiver apenas uma instância primária e nenhuma réplica do Aurora, o endpoint de leitor se conectará à instância primária. Nesse caso, é possível executar operações de gravação por meio do endpoint.O exemplo a seguir ilustra um endpoint de leitor de um cluster de banco de dados do Aurora MySQL.
mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306
- Endpoint personalizado
-
Um endpoint personalizado para um cluster do Aurora representa um conjunto de instâncias de banco de dados escolhido. Quando você se conecta ao endpoint, o Aurora realiza o balanceamento de carga e escolhe uma das instâncias no grupo para processar a conexão. Você define a quais instâncias esse endpoint se refere e determina a finalidade do endpoint.
Um cluster de banco de dados do Aurora não terá endpoints personalizados até você criar um. Você pode criar até cinco endpoints personalizados para cada cluster do Aurora provisionado ou do Aurora Serverless v2. Não use endpoints personalizados em clusters do Aurora Serverless v1.
O endpoint personalizado oferece conexões de banco de dados com carga balanceada baseadas em critérios que não sejam somente leitura ou com recurso de leitura/gravação das instâncias de banco de dados. Por exemplo, convém definir um endpoint personalizado para se conectar a instâncias que usem uma determinada classe de instância da AWS ou determinado parameter group de banco de dados. Em seguida, convém informar grupos particulares sobre esse endpoint personalizado. Por exemplo, convém direcionar usuários internos para instâncias de baixa capacidade tendo em vista a geração de relatórios ou a consulta ad hoc (individual) e direcionar o tráfego da produção para instâncias de alta capacidade.
Como a conexão pode ir para qualquer instância de banco de dados associada ao endpoint personalizado, recomendamos verificar se todas as instâncias de banco de dados dentro desse grupo compartilham algumas características semelhantes. Isso garante que a performance, a capacidade da memória etc. sejam consistentes para todos os conectados a esse endpoint.
Esse recurso se destina a usuários avançados com tipos personalizados de cargas de trabalho em que não seja prático manter todas as réplicas do Aurora no cluster idêntico. Com endpoints personalizados, preveja a capacidade da instância de banco de dados usada em cada conexão. Ao usar endpoints personalizados, você normalmente não usa o endpoint leitor nesse cluster.
O exemplo a seguir ilustra um endpoint personalizado de uma instância de banco de dados em um cluster de banco de dados do Aurora MySQL.
myendpoint.cluster-custom-123456789012.us-east-1.rds.amazonaws.com:3306
- Endpoint da instância
-
Um endpoint de instância se conecta a uma instância de banco de dados específica dentro de um cluster do Aurora. Cada instância de banco de dados em um cluster de banco de dados, tem o próprio endpoint de instância exclusivo. Portanto, existe um endpoint para a instância de banco de dados primária atual do cluster de banco de dados e um endpoint de instância para cada uma das réplicas do Aurora no cluster de banco de dados.
O endpoint de instância oferece controle direto sobre as conexões do cluster de banco de dados, em cenários nos quais usar o endpoint de cluster ou o endpoint de leitor talvez não seja apropriado. Por exemplo, o aplicativo cliente pode exigir um balanceamento de carga mais refinado com base no tipo de workload. Nesse caso, você pode configurar vários clientes para se conectarem a réplicas diferentes do Aurora em um cluster de banco de dados para distribuir cargas de trabalho de leitura. Para ver um exemplo que use endpoints de instância para aumentar a velocidade de conexão após um failover do Aurora PostgreSQL, consulte Failover rápido com o Amazon Aurora PostgreSQL. Para ver um exemplo que usa endpoints de instância para aumentar a velocidade de conexão após um failover do Aurora MySQL, consulte o tópico Suporte a failover do MariaDB Connector/J – caso do Amazon Aurora
. O exemplo a seguir ilustra um endpoint de instância de uma instância de banco de dados em um cluster de banco de dados do Aurora MySQL.
mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306
Visualizar os endpoints de um cluster do Aurora
No AWS Management Console, veja o endpoint cluster, o endpoint leitor e todos os endpoints personalizados na página de detalhes de cada cluster. Você vê o endpoint de instância na página de detalhes de cada instância. Ao se conectar, você deve acrescentar o número da porta associada, seguido de uma vírgula, ao nome do endpoint mostrado nessa página de detalhes.
Com a AWS CLI, você vê os endpoint de gravador, de leitor e qualquer outro personalizado na saída do comando describe-db-clusters. Por exemplo, o comando a seguir mostra os atributos de endpoint para todos os clusters na região atual da AWS.
aws rds describe-db-clusters --query '*[].{Endpoint:Endpoint,ReaderEndpoint:ReaderEndpoint,CustomEndpoints:CustomEndpoints}'
Com a API do Amazon RDS, você recupera os endpoints chamando a função DescribeDBClusterEndpoints.
Usar o endpoint de cluster
Como cada cluster do Aurora tem um único endpoint cluster integrado, cujo nome e outros atributos são gerenciados pelo Aurora, não é possível criar, excluir ou modificar esse tipo de endpoint.
Use o endpoint cluster ao administrar o cluster, realize operações Extract, Transform, Load (ETL – Extração, transformação, carregamento) ou desenvolva e teste aplicações. O endpoint cluster se conecta à instância primária do cluster. A instância primária é a única instância de banco de dados em que você cria tabelas e índices, executa instruções INSERT
e realiza outras operações DDL e DML.
O endereço IP físico apontado pelo endpoint do cluster muda quando o mecanismo de failover promove uma nova instância de banco de dados como a instância primária de leitura/gravação do cluster. Caso você use alguma forma de agrupamento de conexões ou outra multiplexação, prepare-se para enviar ou reduzir a vida útil para todas as informações DNS armazenadas em cache. Isso garante que você não tente estabelecer uma conexão de leitura/gravação com uma instância de banco de dados que fique indisponível ou seja somente leitura após um failover.
Usar o endpoint de leitor
Use o endpoint leitor em conexões somente leitura do cluster do Aurora. O endpoint usa um mecanismo de balanceamento de carga para ajudar o cluster a processar uma workload de consulta intensiva. O endpoint leitor é o endpoint fornecido para aplicações que geram relatórios ou fazem outra operações somente leitura sobre o cluster.
O endpoint de leitor faz o balanceamento da carga das conexões com réplicas do Aurora disponíveis em um cluster de banco de dados do Aurora. Ele não balanceia a carga de consultas individuais. Se você quiser fazer o balanceamento de carga de cada consulta para distribuir a workload de leitura de um cluster de banco de dados, abra uma nova conexão do endpoint de leitor para cada consulta.
Cada cluster do Aurora tem um único endpoint leitor integrado, cujo nome e outros atributos são gerenciados pelo Aurora. Não crie, exclua nem modifique esse tipo de endpoint.
Se o cluster tiver apenas uma instância primária e nenhuma réplica do Aurora, o endpoint de leitor se conectará à instância primária. Nesse caso, é possível executar operações de gravação por meio desse endpoint.
Com o RDS Proxy, você pode criar endpoints somente leitura adicionais para um cluster do Aurora. Esses endpoints realizam o mesmo tipo do balanceamento de carga que endpoint de leitor do Aurora. As aplicações podem se reconectar mais rapidamente aos endpoints do proxy do que o endpoint de leitor do Aurora se as instâncias do leitor ficarem indisponíveis. Os endpoints do proxy também podem tirar proveito de outros recursos de proxy, como a multiplexação. Para obter mais informações, consulte Uso de endpoints de leitor com clusters do Aurora.
Usar endpoints personalizados
Use endpoints personalizados para simplificar o gerenciamento de conexões quando o cluster contém instâncias de banco de dados com configurações de capacidades e configurações diferentes.
Anteriormente, você usava o mecanismo CNAMES para configurar aliases Domain Name Service (DNS – Serviço do nome de domínio) do próprio domínio para atingir resultados semelhantes. Usando endpoints personalizados, evite atualizar registros CNAME quando o cluster cresce ou diminua. Os endpoints personalizados também indicam que é possível usar conexões Transport Layer Security/Secure Sockets Layer (TLS/SSL) criptografadas.
Em vez de usar uma instância de banco de dados para cada finalidade especializada e se conectar ao endpoint de instância, é possível ter vários grupos de instâncias de banco de dados especializadas. Nesse caso, cada grupo tem o próprio endpoint personalizado. Dessa maneira, o Aurora pode realizar o balanceamento de carga entre todas as instâncias dedicadas a tarefas como a geração de relatórios ou o processamento de consultas de produção ou internas. Os endpoints personalizados oferecem balanceamento de carga e alta disponibilidade para cada grupo de instâncias de banco de dados dentro do cluster. Caso uma das instâncias de banco de dados dentro de um grupo se torne indisponível, o Aurora direciona conexões de endpoint personalizadas subsequentes para uma das outras instâncias de banco de dados associadas ao mesmo endpoint.
Tópicos
Especificar propriedades para endpoints personalizados
O tamanho máximo do nome de um endpoint personalizado é 63 caracteres. Veja o seguinte formato do nome:
endpointName
.cluster-custom-customerDnsIdentifier
.dnsSuffix
Como os nomes de endpoint personalizados não incluem o nome do cluster, você vai precisa alterar esses nomes se renomear um cluster. Não é possível reutilizar o mesmo nome de endpoint personalizado em mais de um cluster na mesma região. Atribua a cada endpoint personalizado um nome que seja exclusivo entre os clusters de propriedade do ID do usuário dentro de uma região específica.
Cada endpoint personalizado tem um tipo associado que determina quais instâncias de banco de dados estão qualificadas para serem associadas a esse endpoint. Atualmente, o tipo pode ser READER
, WRITER
ou ANY
. As seguintes considerações se aplicam aos tipos de endpoint personalizados:
-
Não selecione o tipo de endpoint personalizado no AWS Management Console. Todos os endpoints personalizados criados por meio do AWS Management Console têm um tipo de
ANY
.Você pode definir e modificar o tipo de endpoint personalizado usando a AWS CLI ou a API do Amazon RDS.
-
Somente instâncias de banco de dados que sejam réplicas do Aurora somente leitura podem fazer parte de um endpoint personalizado do
READER
. O tipoREADER
só se aplica a clusters que usem replicação de mestre único, porque esses clusters podem incluir várias instâncias de banco de dados somente leitura. -
As réplicas do Aurora somente leitura e a instância primária de leitura/gravação podem fazer parte de um endpoint personalizado
ANY
. O Aurora direciona conexões para endpoints de cluster do tipoANY
para qualquer instância de banco de dados associada com probabilidade igual. Como não é possível determinar com antecedência se você está se conectando à instância primária de uma réplica do Aurora somente leitura, use esse tipo de endpoint apenas em conexões somente leitura. O tipoANY
se aplica a clusters que usam uma topologia de replicação. -
O tipo
WRITER
só se aplica a clusters que usem replicação de vários mestres, pois esses clusters podem incluir várias instâncias de banco de dados de leitura/gravação. -
Caso você tente criar um endpoint personalizado com um tipo que não seja apropriado com base na configuração de replicação para um cluster, Aurora retorna um erro.
Regras de associação para endpoints personalizados
Quando você adiciona uma instância de banco de dados a um endpoint personalizado ou a remove de um endpoint personalizado, todas as conexões existentes com essa instância de banco de dados permanecem ativas.
Defina uma lista de instâncias de banco de dados para serem incluídas em ou excluídas de um endpoint personalizado. Nós nos referimos a essas listas como estáticas e exclusão, respectivamente. Use o mecanismo de inclusão/exclusão para subdividir ainda mais os grupos de instâncias de banco de dados e verifique se o conjunto de endpoints personalizados abrange todas as instâncias de banco de dados no cluster. Cada endpoint personalizado só pode conter um desses tipos de lista.
No AWS Management Console:
-
A escolha é representada pela caixa de seleção Attach future instances added to this cluster (Anexar instâncias futuras adicionadas a esse cluster). Quando você mantém a caixa de seleção desmarcada, o endpoint personalizado usa uma lista estática contendo apenas as instâncias de banco de dados especificadas na página. Quando você marca a caixa de seleção, o endpoint personalizado usa uma lista de exclusões. Nesse caso, o endpoint personalizado representa todas as instâncias de banco de dados no cluster (inclusive as adicionadas futuramente), exceto as desmarcadas na caixa de diálogo.
-
O Aurora altera as instâncias de banco de dados especificadas nas listas estáticas ou de exclusão quando as instâncias de banco de dados mudam de perfil entre gravadora e leitora por causa do failover ou da promoção.
Por exemplo, um endpoint personalizado com o tipo
READER
inclui uma réplica do Aurora que, depois, é promovida para uma instância gravadora. A nova instância gravadora não faz mais parte do endpoint personalizado.
Na AWS CLI e na API do Amazon RDS:
-
O Aurora não altera as instâncias de banco de dados especificadas nas listas estáticas ou de exclusão quando as instâncias de banco de dados mudam de perfil entre gravadora e leitora por causa do failover ou da promoção.
Por exemplo, um endpoint personalizado com o tipo
READER
inclui uma réplica do Aurora que, depois, é promovida para uma instância gravadora. O tipo de endpoint personalizado (READER
,WRITER
ouANY
) determina quais tipos de operações é possível executar por meio desse endpoint. -
Você pode adicionar membros individuais e removê-los das listas depois que eles mudam de perfil. Use o comando modify-db-cluster-endpoint
da AWS CLI ou a operação de API ModifyDBClusterEndpoint.
Associe uma instância de banco de dados a mais de um endpoint personalizado. Por exemplo, suponhamos que você adicione uma nova instância de banco de dados a um cluster, ou esse Aurora adiciona uma instância de banco de dados automaticamente por meio do mecanismo dimensionável. Nesses casos, a instância de banco de dados é adicionada a todos os endpoints personalizados para os quais está qualificada. A quais endpoints a instância de banco de dados é adicionada depende do tipo de endpoint personalizado de READER
, WRITER
ou ANY
, além de todas as listas estáticas e de exclusões definidas para cada endpoint. Por exemplo, se o endpoint incluir uma lista estática de instâncias de banco de dados, as réplicas do Aurora recém-adicionadas não serão adicionadas a esse endpoint. Por outro lado, se o endpoint tiver uma lista de exclusões, as réplicas do Aurora recém-adicionadas serão adicionadas ao endpoint se não estiverem nomeadas na lista de exclusões e as funções corresponderem ao tipo do endpoint personalizado.
Caso se torne indisponível, uma réplica do Aurora continua associada a todos os endpoints personalizados. Por exemplo, ela continua fazendo parte do endpoint personalizado quando não há integridade, ela está parada, na reinicialização e assim por diante. Porém, não será possível se conectar a ela por meio desses endpoints até ela estar disponível novamente.
Gerenciar endpoints personalizados
Como clusters do Aurora recém-criados não têm endpoints personalizados, crie e gerencie esses objetos por conta própria. Faça isso usando o AWS Management Console, a AWS CLI ou a API do Amazon RDS.
Também crie e gerencie endpoints personalizados para clusters do Aurora restaurados de snapshots. Os endpoints personalizados não estão incluídos no snapshot. Você os recriará depois de restaurar e escolherá novos nomes de endpoint se o cluster restaurado estiver na mesma região do original.
Para trabalhar com endpoints personalizados no AWS Management Console, navegue até a página de detalhes do cluster do Aurora e use os controles na seção Custom Endpoints (Endpoints personalizados).
Para trabalhar com endpoints personalizados da AWS CLI, use estas operações:
Para trabalhar com endpoints personalizados por meio da API do Amazon RDS, use as seguintes funções:
Criar um endpoint personalizado
Para criar um endpoint personalizado com o AWS Management Console, vá até a página de detalhes do cluster e escolha a ação Create custom endpoint
na seção Endpoints. Escolha um nome para o endpoint personalizado, exclusivo para o ID do usuário e a região. Para escolher uma lista de instâncias de banco de dados que permaneça a mesma mesmo quando o cluster se expande, mantenha a caixa de seleção Attach future instances added to this cluster (Anexar instâncias futuras adicionadas a esse cluster) desmarcada. Quando você marca essa caixa de seleção, o endpoint personalizado adiciona de maneira dinâmica todas as novas instâncias ao adicioná-las ao cluster.

Não selecione o tipo de endpoint personalizado de ANY
ou READER
no AWS Management Console. Todos os endpoints personalizados criados por meio do AWS Management Console têm um tipo de ANY
.
Para criar um endpoint personalizado com a AWS CLI, execute o comando create-db-cluster-endpoint.
O comando a seguir cria um endpoint personalizado anexado a um cluster específico. Inicialmente, o endpoint é associado a todas as instâncias de réplica do Aurora no cluster. Um comando subsequente o associa a um conjunto específico de instâncias de banco de dados no cluster.
Para Linux, macOS ou Unix:
aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample \ --endpoint-type reader \ --db-cluster-identifier
cluster_id
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample \ --static-membersinstance_name_1
instance_name_2
Para Windows:
aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample ^ --endpoint-type reader ^ --db-cluster-identifier
cluster_id
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample ^ --static-membersinstance_name_1
instance_name_2
Para criar um endpoint personalizado com a API do RDS, execute a operação CreateDBClusterEndpoint.
Visualizar endpoints personalizados
Para visualizar endpoints personalizados com o AWS Management Console, vá até a página de detalhes do cluster e veja a seção Endpoints. Esta seção contém informações apenas sobre endpoints personalizados. Os detalhes dos endpoints integrados estão listados na seção Details (Detalhes) principal. Para ver os detalhes de um endpoint personalizado específico, selecione o nome para abrir a página de detalhes desse endpoint.
A captura de tela a seguir mostra como a lista de endpoints personalizados de um cluster do Aurora está inicialmente vazia.

Depois que você cria alguns endpoints personalizados para esse cluster, eles são mostrados na seção Endpoints.

Clicar na página de detalhes mostra a quais instâncias de banco de dados o endpoint está associado no momento.

Para ver os outros detalhes sobre se novas instâncias de banco de dados adicionadas ao cluster são incluídas automaticamente no endpoint, abra a página Edit (Editar) do endpoint.
Para visualizar endpoints personalizados com a AWS CLI, execute o comando describe-db-cluster-endpoints.
O comando a seguir mostra os endpoints personalizados associados a um cluster especificado em uma região especificada. A saída inclui os endpoints integrados e todos os endpoints personalizados.
Para Linux, macOS ou Unix:
aws rds describe-db-cluster-endpoints --region
region_name
\ --db-cluster-identifiercluster_id
Para Windows:
aws rds describe-db-cluster-endpoints --region
region_name
^ --db-cluster-identifiercluster_id
Isto mostra algumas saídas de exemplo de um comando describe-db-cluster-endpoints
. O EndpointType
de WRITER
ou READER
denota os endpoints de leitura/gravação e somente leitura integrados do cluster. O EndpointType
de CUSTOM
denota endpoints criados e escolha as instâncias de banco de dados associadas. Um dos endpoints tem um campo StaticMembers
não vazio, denotando que ele está associado a um conjunto preciso de instâncias de banco de dados. O outro endpoint tem um campo ExcludedMembers
não vazio, denotando que o endpoint está associado a todas as instâncias de banco de dados diferentes das listadas em ExcludedMembers
. Esse segundo tipo de endpoint personalizado cresce para acomodar novas instâncias à medida que você as adiciona ao cluster.
{ "DBClusterEndpoints": [ { "Endpoint": "custom-endpoint-demo.cluster-123456789012.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo", "EndpointType": "WRITER" }, { "Endpoint": "custom-endpoint-demo.cluster-ro-123456789012.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo", "EndpointType": "READER" }, { "CustomEndpointType": "ANY", "DBClusterEndpointIdentifier": "powers-of-2", "ExcludedMembers": [], "DBClusterIdentifier": "custom-endpoint-demo", "Status": "available", "EndpointType": "CUSTOM", "Endpoint": "powers-of-2.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "StaticMembers": [ "custom-endpoint-demo-04", "custom-endpoint-demo-08", "custom-endpoint-demo-01", "custom-endpoint-demo-02" ], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:powers-of-2" }, { "CustomEndpointType": "ANY", "DBClusterEndpointIdentifier": "eight-and-higher", "ExcludedMembers": [ "custom-endpoint-demo-04", "custom-endpoint-demo-02", "custom-endpoint-demo-07", "custom-endpoint-demo-05", "custom-endpoint-demo-03", "custom-endpoint-demo-06", "custom-endpoint-demo-01" ], "DBClusterIdentifier": "custom-endpoint-demo", "Status": "available", "EndpointType": "CUSTOM", "Endpoint": "eight-and-higher.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "StaticMembers": [], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHYQKFU6J6NV5FHU", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:eight-and-higher" } ] }
Para visualizar endpoints personalizados com a API do RDS, execute a operação DescribeDBClusterEndpoints.html.
Editar um endpoint personalizado
Edite as propriedades de um endpoint personalizado para alterar quais instâncias de banco de dados estão associadas ao endpoint. Também altere um endpoint entre uma lista estática e uma lista de exclusões. Se você precisar de mais detalhes sobre essas propriedades de endpoint, consulte Regras de associação para endpoints personalizados.
Você pode continuar se conectando e usando um endpoint personalizado enquanto as alterações em uma ação de edição estiverem em andamento.
Para editar um endpoint personalizado com o AWS Management Console, selecione o endpoint na página de detalhes do cluster ou abra a página de detalhes do endpoint e escolha a ação Edit (Editar).

Para editar um endpoint personalizado com a AWS CLI, execute o comando modify-db-cluster-endpoint.
Os comandos a seguir alteram o conjunto de instâncias de banco de dados que se aplicam a um endpoint personalizado e podem alternar o comportamento de uma lista estática ou de exclusões. Os parâmetros --static-members
e --excluded-members
utilizam uma lista separada por espaços de identificadores de instância de banco de dados.
Para Linux, macOS ou Unix:
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier
my-custom-endpoint
\ --static-membersdb-instance-id-1
db-instance-id-2
db-instance-id-3
\ --regionregion_name
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifiermy-custom-endpoint
\ --excluded-membersdb-instance-id-4
db-instance-id-5
\ --regionregion_name
Para Windows:
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier
my-custom-endpoint
^ --static-membersdb-instance-id-1
db-instance-id-2
db-instance-id-3
^ --regionregion_name
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifiermy-custom-endpoint
^ --excluded-membersdb-instance-id-4
db-instance-id-5
^ --regionregion_name
Para editar um endpoint personalizado com a API do RDS, execute a operação ModifyDBClusterEndpoint.html.
Excluir um endpoint personalizado
Para excluir um endpoint personalizado com o AWS Management Console, vá até a página de detalhes do cluster, selecione o endpoint personalizado apropriado e a ação Delete (Excluir).

Para excluir um endpoint personalizado com a AWS CLI, execute o comando delete-db-cluster-endpoint.
O comando a seguir exclui um endpoint personalizado. Você não precisa especificar o cluster associado, mas deve especificar a região.
Para Linux, macOS ou Unix:
aws rds delete-db-cluster-endpoint --db-cluster-endpoint-identifier
custom-end-point-id
\ --regionregion_name
Para Windows:
aws rds delete-db-cluster-endpoint --db-cluster-endpoint-identifier
custom-end-point-id
^ --regionregion_name
Para excluir um endpoint personalizado com a API do RDS, execute a operação DeleteDBClusterEndpoint.
Exemplo da AWS CLI de ponta a ponta para endpoints personalizados
O tutorial a seguir usa exemplos da AWS CLI com sintaxe do shell do Unix para mostrar que convém definir um cluster com várias instâncias de banco de dados “pequenas” e algumas instâncias de banco de dados “grandes” e criar endpoints personalizados para se conectar a cada conjunto de instâncias de banco de dados. Para executar comandos semelhantes no próprio sistema, você deve estar familiarizado com os conceitos básicos de trabalhar com clusters do Aurora e o uso da AWS CLI para fornecer os valores próprios de parâmetros, como região, grupo de sub-redes e grupo de segurança da VPC.
Este exemplo demonstra as etapas de configuração iniciais: criar um cluster do Aurora e adicionar instâncias de banco de dados a ele. Este é um cluster heterogêneo, o que significa que nem todas as instâncias de banco de dados têm a mesma capacidade. A maioria das instâncias usa a classe AWS da instância da db.r4.4xlarge
, mas as últimas duas instâncias de banco de dados usam db.r4.16xlarge
. Cada um desses comandos create-db-instance
de exemplo imprime a saída na tela e salva uma cópia do JSON em um arquivo para inspeção posterior.
aws rds create-db-cluster --db-cluster-identifier custom-endpoint-demo --engine aurora \ --engine-version 5.6.10a --master-username $MASTER_USER --master-user-password $MASTER_PW \ --db-subnet-group-name $SUBNET_GROUP --vpc-security-group-ids $VPC_SECURITY_GROUP \ --region $REGION for i in 01 02 03 04 05 06 07 08 do aws rds create-db-instance --db-instance-identifier custom-endpoint-demo-${i} \ --engine aurora --db-cluster-identifier custom-endpoint-demo --db-instance-class db.r4.4xlarge \ --region $REGION \ | tee custom-endpoint-demo-${i}.json done for i in 09 10 do aws rds create-db-instance --db-instance-identifier custom-endpoint-demo-${i} \ --engine aurora --db-cluster-identifier custom-endpoint-demo --db-instance-class db.r4.16xlarge \ --region $REGION \ | tee custom-endpoint-demo-${i}.json done
As instâncias maiores são reservadas para tipos especializados de consultas de relatórios. Para a impossibilidade de que elas sejam promovidas para a instância primária, o exemplo a seguir altera o nível de promoção para a menor prioridade.
for i in 09 10 do aws rds modify-db-instance --db-instance-identifier custom-endpoint-demo-${i} \ --region $REGION --promotion-tier 15 done
Vamos supor que você queira usar as duas instâncias “maiores” apenas para as consultas que exijam mais recursos. Para fazer isso, primeiro é possível criar um endpoint somente leitura personalizado. Depois disso, é possível adicionar uma lista estática de membros para que o endpoint se conecte somente a essas instâncias de banco de dados. Essas instâncias já estão no nível de promoção mais baixo, tornando improvável que elas sequer sejam promovidas para a instância primária. Se uma delas for promovida para a instância primária, não será alcançável por meio desse endpoint porque especificamos o tipo READER
, em vez do tipo ANY
.
O exemplo a seguir demonstra os comandos de criação e modificação do endpoint, além da saída JSON de exemplo, mostrando o estado inicial e modificado do endpoint personalizado.
$
aws rds create-db-cluster-endpoint --region $REGION \ --db-cluster-identifier custom-endpoint-demo \ --db-cluster-endpoint-identifier big-instances --endpoint-type reader{ "EndpointType": "CUSTOM", "Endpoint": "big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "DBClusterEndpointIdentifier": "big-instances", "DBClusterIdentifier": "custom-endpoint-demo", "StaticMembers": [], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "ExcludedMembers": [], "CustomEndpointType": "READER", "Status": "creating", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-instances" }
$
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier big-instances \ --static-members custom-endpoint-demo-09 custom-endpoint-demo-10 --region $REGION{ "EndpointType": "CUSTOM", "ExcludedMembers": [], "DBClusterEndpointIdentifier": "big-instances", "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "CustomEndpointType": "READER", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-instances", "StaticMembers": [ "custom-endpoint-demo-10", "custom-endpoint-demo-09" ], "Status": "modifying", "Endpoint": "big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "DBClusterIdentifier": "custom-endpoint-demo" }
O endpoint READER
padrão do cluster pode se conectar a instâncias de banco de dados “pequenas” ou “grandes”, tornando impraticável prever a performance da consulta e a escalabilidade quando o cluster fica ocupado. Para dividir a workload claramente entre os conjuntos de instâncias de banco de dados, ignore o endpoint READER
padrão e crie um segundo endpoint personalizado que se conecte a todas as outras instâncias de banco de dados. O exemplo a seguir faz isso criando um endpoint personalizado e adicionando uma lista de exclusões. Todas as outras instâncias de banco de dados adicionadas ao cluster depois serão adicionadas a esse endpoint automaticamente. O tipo ANY
significa que esse endpoint está associado a oito instâncias no total: a instância primária e outras sete réplicas do Aurora. Se o exemplo tivesse usado o tipo READER
, o endpoint personalizado só estaria associado às sete réplicas do Aurora.
$
aws rds create-db-cluster-endpoint --region $REGION --db-cluster-identifier custom-endpoint-demo \ --db-cluster-endpoint-identifier small-instances --endpoint-type any{ "Status": "creating", "DBClusterEndpointIdentifier": "small-instances", "CustomEndpointType": "ANY", "EndpointType": "CUSTOM", "Endpoint": "small-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "StaticMembers": [], "ExcludedMembers": [], "DBClusterIdentifier": "custom-endpoint-demo", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:small-instances", "DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY" }
$
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier small-instances \ --excluded-members custom-endpoint-demo-09 custom-endpoint-demo-10 --region $REGION{ "DBClusterEndpointIdentifier": "small-instances", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:small-instances", "DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY", "CustomEndpointType": "ANY", "Endpoint": "small-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "EndpointType": "CUSTOM", "ExcludedMembers": [ "custom-endpoint-demo-09", "custom-endpoint-demo-10" ], "StaticMembers": [], "DBClusterIdentifier": "custom-endpoint-demo", "Status": "modifying" }
O exemplo a seguir verifica o estado dos endpoints desse cluster. O cluster ainda tem o endpoint cluster original, com EndPointType
de WRITER
, que você continuaria usando nas operações de administração, ETL e outras de gravação. Ele ainda tem o endpoint READER
original, que você não usaria porque cada conexão com ele pode ser direcionada para uma instância de banco de dados “pequena” ou “grande”. Os endpoints personalizados tornam esse comportamento previsível, com conexões garantidas para usar uma das instâncias de banco de dados “pequena” ou “grande” com base no endpoint especificado.
$
aws rds describe-db-cluster-endpoints --region $REGION{ "DBClusterEndpoints": [ { "EndpointType": "WRITER", "Endpoint": "custom-endpoint-demo.cluster-123456789012.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo" }, { "EndpointType": "READER", "Endpoint": "custom-endpoint-demo.cluster-ro-123456789012.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo" }, { "Endpoint": "small-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "CustomEndpointType": "ANY", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:small-instances", "ExcludedMembers": [ "custom-endpoint-demo-09", "custom-endpoint-demo-10" ], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY", "DBClusterIdentifier": "custom-endpoint-demo", "StaticMembers": [], "EndpointType": "CUSTOM", "DBClusterEndpointIdentifier": "small-instances", "Status": "modifying" }, { "Endpoint": "big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "CustomEndpointType": "READER", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-instances", "ExcludedMembers": [], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "DBClusterIdentifier": "custom-endpoint-demo", "StaticMembers": [ "custom-endpoint-demo-10", "custom-endpoint-demo-09" ], "EndpointType": "CUSTOM", "DBClusterEndpointIdentifier": "big-instances", "Status": "available" } ] }
Os exemplos finais demonstram como conexões de banco de dados sucessivas com os endpoints personalizados se ligam às várias instâncias de banco de dados no cluster do Aurora. O endpoint small-instances
sempre se conecta às instâncias de banco de dados db.r4.4xlarge
, que são hosts de números mais baixos nesse cluster.
$
mysql -h small-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u $MYUSER -pmysql>
select @@aurora_server_id;+-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-02 | +-------------------------+
$
mysql -h small-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u $MYUSER -pmysql>
select @@aurora_server_id;+-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-07 | +-------------------------+
$
mysql -h small-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u $MYUSER -pmysql>
select @@aurora_server_id;+-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-01 | +-------------------------+
O endpoint big-instances
sempre se conecta às instâncias de banco de dados db.r4.16xlarge
, que são os dois hosts de números mais altos nesse cluster.
$
mysql -h big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u $MYUSER -pmysql>
select @@aurora_server_id;+-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-10 | +-------------------------+
$
mysql -h big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u $MYUSER -pmysql>
select @@aurora_server_id;+-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-09 | +-------------------------+
Usar os endpoints de instância
Cada instância de banco de dados em um cluster do Aurora tem o próprio endpoint de instância integrado, cujo nome e outros atributos são gerenciados pelo Aurora. Não crie, exclua nem modifique esse tipo de endpoint. Se você usa o Amazon RDS, pode estar familiarizado com endpoints de instância. No entanto, com o Aurora normalmente você usa os endpoints de leitor e de gravador com mais frequência do que os endpoints de instância.
Nas operações diárias do Aurora, a principal maneira de usar endpoints de instância é fazer o diagnóstico dos problemas de capacidade ou de performance que afetam uma instância específica em um cluster do Aurora. Conectado a uma instância específica, examine as variáveis de status, as métricas etc. Fazer isso pode ajudar a determinar o que está acontecendo nessa instância diferente do que está acontecendo com outras instâncias no cluster.
Em casos de uso avançados, convém configurar algumas instâncias de banco de dados de maneira diferente de outras. Nesse caso, use o endpoint de instância para se conectar diretamente a uma instância que seja menor, maior ou tenha características diferentes das outras. Além disso, configure a prioridade de failover, de maneira que essa instância de banco de dados especial seja a última opção a ser tomada como a instância primária. Recomendamos usar endpoints personalizados, em vez do endpoint de instância nesses casos. Isso simplifica o gerenciamento de conexões e a alta disponibilidade à medida que você adiciona mais instâncias de banco de dados ao cluster.
Como os endpoints do Aurora funcionam com alta disponibilidade
Para clusters em que a alta disponibilidade é importante, use o endpoint de gravador para conexões de leitura/gravação ou de uso geral e o endpoint de leitor para conexões somente leitura. Os endpoints de leitor e de gravador gerenciam o failover da instância de banco de dados melhor do que os endpoints de instância. Ao contrário dos endpoints de instância, os endpoints de leitor e de gravador alteram automaticamente a qual instância de banco de dados eles se conectam caso uma instância de banco de dados no cluster fique indisponível.
Se a instância de banco de dados primária de um cluster de banco de dados falhar, o Aurora fará failover automático para uma nova instância de banco de dados primária. Ela faz isso promovendo uma réplica do Aurora existente para uma nova instância de banco de dados primária ou criando uma nova instância de banco de dados primária. Se ocorrer um failover, será possível usar o endpoint de gravador para se reconectar à instância de banco de dados primária recém-promovida ou criada ou usar o endpoint de leitor para se reconectar a uma das réplicas do Aurora no cluster de banco de dados. Durante um failover, o endpoint de leitor pode direcionar conexões para a nova instância de banco de dados primária de um cluster de banco de dados por um curto período depois que uma réplica do Aurora é promovida para a nova instância de banco de dados primária.
Caso projete a própria lógica de aplicativo para gerenciar conexões com endpoints de instância, descubra de maneira manual ou programática o conjunto resultante de instâncias de banco de dados disponíveis no cluster de banco de dados. Use o comando describe-db-clusters da AWS CLI ou a operação DescribeDBClusters da API do RDS para encontrar o cluster de banco de dados, os endpoints leitores e as instâncias de banco de dados, e identificar se as instâncias de banco de dados são leitoras e quais seus níveis de promoção. Em seguida, confirme as classes de instância após o failover e se conecte a um endpoint de instância apropriado.
Para obter mais informações sobre failovers, consulte Tolerância a falhas para um cluster de banco de dados do Aurora.