Usar o encaminhamento de gravação em um banco de dados global do Aurora PostgreSQL
Tópicos
- Disponibilidade de região e versão do encaminhamento de gravação no Aurora PostgreSQL
- Ativar o encaminhamento de gravação no Aurora PostgreSQL
- Verificar se um cluster secundário está com o encaminhamento de gravação ativado no Aurora PostgreSQL
- Compatibilidade do SQL e de aplicações com o encaminhamento de gravação no Aurora PostgreSQL
- Isolamento e consistência para o encaminhamento de gravação no Aurora PostgreSQL
- Executar instruções de várias partes com o encaminhamento de gravação no Aurora PostgreSQL
- Parâmetros de configuração para o encaminhamento de gravação no Aurora PostgreSQL
- Métricas do Amazon CloudWatch para o encaminhamento de gravação no Aurora PostgreSQL
- Eventos de espera para encaminhamento de gravação no Aurora PostgreSQL
Disponibilidade de região e versão do encaminhamento de gravação no Aurora PostgreSQL
No Aurora PostgreSQL versão 16 e versões principais posteriores, o encaminhamento global de gravação é possível em todas as versões secundárias. Para versões anteriores do Aurora PostgreSQL, o encaminhamento global de gravação é possível na versão 15.4 e em versões secundárias posteriores e na versão 14.9 e em versões secundárias posteriores. O encaminhamento de gravação está disponível em todas as regiões da AWS em que os bancos de dados globais baseados no Aurora PostgreSQL estão disponíveis.
Para ter mais informações sobre a disponibilidade de versões e regiões dos bancos de dados globais Aurora, consulte Bancos de dados globais do Aurora com o Aurora PostgreSQL.
Ativar o encaminhamento de gravação no Aurora PostgreSQL
Por padrão, o encaminhamento de gravação não está habilitado quando você adiciona um cluster secundário a um banco de dados global Aurora. Você pode ativar o encaminhamento de gravação para seu cluster de banco de dados secundário enquanto o cria ou a qualquer momento depois de criá-lo. Se necessário, você pode desativá-lo mais tarde. Ativar ou desativar o encaminhamento de gravação não causa tempo de inatividade ou reinicialização.
No console, você pode ativar ou desativar o encaminhamento de gravação ao criar ou modificar um cluster de banco de dados secundário.
Ativar ou desativar o encaminhamento de gravação ao criar um cluster de banco de dados secundário
Ao criar um cluster de banco de dados secundário, você ativa o encaminhamento de gravação marcando a caixa de seleção Ativar encaminhamento de gravação global em Ler o encaminhamento de gravação da réplica. Para desativá-lo, desmarque a caixa de seleção. Para criar um cluster de banco de dados secundário, siga as instruções relacionadas ao seu mecanismo de banco de dados em Criar um cluster de bancos de dados do Amazon Aurora.
A captura de tela a seguir mostra a seção Ler o encaminhamento de gravação da réplica com a caixa de seleção Ativar encaminhamento de gravação global marcada.
Ativar ou desativar o encaminhamento de gravação ao modificar um cluster de banco de dados secundário
No console, você pode modificar um cluster de banco de dados secundário ou desativar o encaminhamento de gravação.
No console, para ativar ou desativar o encaminhamento de gravação para um cluster de banco de dados secundário
Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/
. -
Escolha Databases (Bancos de dados).
-
Escolha o cluster de banco de dados secundário e selecione Modificar.
-
Na seção Ler o encaminhamento de gravação da réplica, marque ou desmarque a caixa de seleção Ativar encaminhamento de gravação global.
-
Escolha Continuar.
-
Em Programar modificações, selecione Aplicar imediatamente. Se você escolher Aplicar durante a próxima janela de manutenção agendada, o Aurora ignorará essa configuração e ativará o encaminhamento de gravação imediatamente.
-
Escolha Modificar cluster.
Para ativar o encaminhamento de gravação pela AWS CLI, use a opção --enable-global-write-forwarding
. Essa opção funciona quando você cria um cluster secundário usando o comando create-db-cluster. Ela também funciona quando você modifica um cluster secundário existente usando o comando modify-db-cluster. Para isso, é necessário que o banco de dados global use uma versão do Aurora que ofereça suporte ao encaminhamento de gravação. É possível desabilitar o encaminhamento de gravação usando a opção --no-enable-global-write-forwarding
com esses mesmos comandos da CLI.
Os procedimentos a seguir descrevem como ativar ou desativar o encaminhamento de gravação para um cluster de banco de dados secundário no cluster global usando a AWS CLI.
Para ativar ou desativar o encaminhamento de gravação para um cluster de banco de dados secundário existente
-
Chame o comando modify-db-cluster AWS CLI e forneça os seguintes valores:
-
--db-cluster-identifier
: o nome do cluster de banco de dados. -
--enable-global-write-forwarding
para ativar ou--no-enable-global-write-forwarding
para desativar.
O exemplo a seguir permite o encaminhamento de gravação para o cluster
sample-secondary-db-cluster
de banco de dados.Para Linux, macOS ou Unix:
aws rds modify-db-cluster \ --db-cluster-identifier sample-secondary-db-cluster \ --enable-global-write-forwarding
Para Windows:
aws rds modify-db-cluster ^ --db-cluster-identifier sample-secondary-db-cluster ^ --enable-global-write-forwarding
-
Para habilitar o encaminhamento de gravação usando a API do Amazon RDS, defina o parâmetro EnableGlobalWriteForwarding
como true
. Esse parâmetro funciona quando você cria um cluster secundário usando a operação CreateDBCluster. Ele também funciona quando você modifica um cluster secundário existente usando a operação ModifyDBCluster. Para isso, é necessário que o banco de dados global use uma versão do Aurora que ofereça suporte ao encaminhamento de gravação. É possível desabilitar o encaminhamento de gravação definindo o parâmetro EnableGlobalWriteForwarding
como false
.
Verificar se um cluster secundário está com o encaminhamento de gravação ativado no Aurora PostgreSQL
Para determinar se é possível usar o encaminhamento de gravação em um cluster secundário, verifique se esse cluster tem o atributo "GlobalWriteForwardingStatus": "enabled"
.
No AWS Management Console, é exibido Read replica write forwarding
na guia Configuração da página de detalhes do cluster. Para ver o status da configuração de encaminhamento de gravação global para todos os clusters, execute o seguinte comando da AWS CLI.
Um cluster secundário mostra o valor "enabled"
ou "disabled"
para indicar se o encaminhamento de gravação está ativado ou desativado. Um valor de null
indica que o encaminhamento de gravação não está disponível para esse cluster. Nesse caso, o cluster não faz parte de um banco de dados global ou é o cluster primário em vez de um cluster secundário. O valor também poderá ser "enabling"
ou "disabling"
se o encaminhamento de gravação estiver no processo de ser ativado ou desativado.
exemplo
aws rds describe-db-clusters --query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}' [ { "GlobalWriteForwardingStatus": "enabled", "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1" }, { "GlobalWriteForwardingStatus": "disabled", "DBClusterIdentifier": "aurora-write-forwarding-test-replica-2" }, { "GlobalWriteForwardingStatus": null, "DBClusterIdentifier": "non-global-cluster" } ]
Para localizar apenas os clusters secundários que têm o encaminhamento de gravação global habilitado, execute o comando a seguir. Este comando também retorna o endpoint do leitor do cluster. Use o endpoint do leitor do cluster secundário ao usar o encaminhamento de gravação do secundário para o primário no banco de dados global Aurora.
exemplo
aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]' [ { "GlobalWriteForwardingStatus": "enabled", "ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com", "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1" } ]
Compatibilidade do SQL e de aplicações com o encaminhamento de gravação no Aurora PostgreSQL
Certas instruções não são permitidas ou podem gerar resultados obsoletos ao serem usadas em um banco de dados global com o encaminhamento de gravação. Além disso, funções definidas pelo usuário e procedimentos definidos pelo usuário não são compatíveis. Assim, a configuração EnableGlobalWriteForwarding
é desativada por padrão para clusters secundários. Antes de ativá-la, verifique se o código do aplicativo não é afetado por nenhuma dessas restrições.
É possível usar os seguintes tipos de instruções SQL com o encaminhamento de gravação:
-
Instruções de linguagem de manipulação de dados (DML), como
INSERT
,DELETE
eUPDATE
. -
Instruções
SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }
-
Instruções
PREPARE
eEXECUTE
. -
Instruções
EXPLAIN
com as instruções desta lista
Os seguintes tipos de instruções SQL não são compatíveis com o encaminhamento de gravação:
-
Instruções Data Definition Language (DDL)
-
ANALYZE
-
CLUSTER
-
COPY
-
Cursores: os cursores não são compatíveis, então feche-os antes de usar o encaminhamento de gravação.
-
GRANT
|REVOKE
|REASSIGN OWNED
|SECURITY LABEL
-
LOCK
-
Instruções
SAVEPOINT
-
SELECT INTO
-
SET CONSTRAINTS
-
TRUNCATE
-
VACUUM
Isolamento e consistência para o encaminhamento de gravação no Aurora PostgreSQL
Em sessões que usam o encaminhamento de gravação, é possível usar os níveis de isolamento REPEATABLE READ
e READ COMMITTED
. No entanto, o nível de isolamento SERIALIZABLE
não é compatível.
É possível controlar o grau de consistência de leitura em um cluster secundário. O nível de consistência de leitura determina quanto o cluster secundário espera antes de cada operação de leitura para garantir que algumas ou todas as alterações sejam replicadas do cluster primário. Você pode ajustar o nível de consistência de leitura para garantir que todas as operações de gravação encaminhadas da sessão estejam visíveis no cluster secundário antes de qualquer consulta subsequente. Você também pode usar essa configuração para garantir que as consultas no cluster secundário sempre vejam as atualizações mais atuais do cluster primário. Isso acontece mesmo para aquelas submetidas por outras sessões ou outros clusters. Para especificar esse tipo de comportamento para a aplicação, escolha o valor apropriado para o parâmetro apg_write_forward.consistency_mode
de nível de sessão. O parâmetro apg_write_forward.consistency_mode
tem efeito somente em clusters secundários nos quais o encaminhamento de gravação está habilitado.
nota
Para o parâmetro apg_write_forward.consistency_mode
, é possível especificar o valor SESSION
, EVENTUAL
, GLOBAL
ou OFF
. Por padrão, o valor é definido como SESSION
. Definir o valor como OFF
desativa o encaminhamento de gravação na sessão.
À medida que você aumenta o nível de consistência, a aplicação passa mais tempo aguardando as alterações serem propagadas entre regiões da AWS. Você pode escolher o equilíbrio entre o tempo de resposta rápido e a garantia de que as alterações feitas em outros locais estejam totalmente disponíveis antes da execução das consultas.
Com cada configuração de modo de consistência disponível, o efeito é o seguinte:
SESSION
: todas as consultas em uma região secundária da AWS que usa o encaminhamento de gravação veem os resultados de todas as alterações feitas nessa sessão. As alterações são visíveis independentemente de a transação ser confirmada. Se necessário, a consulta aguardará que os resultados das operações de gravação encaminhadas sejam replicados para a região atual. Ele não aguarda resultados atualizados de operações de gravação realizadas em outras regiões ou em outras sessões da região atual.EVENTUAL
: as consultas em uma região secundária da AWS que usa o encaminhamento de gravação podem ver dados ligeiramente obsoletos devido ao atraso de replicação. Os resultados das operações de gravação na mesma sessão não ficam visíveis até que a operação de gravação seja executada na região primária e replicada para a região atual. A consulta não espera que os resultados atualizados estejam disponíveis. Assim, ela pode recuperar os dados mais antigos ou os dados atualizados, dependendo do tempo das declarações e da quantidade de atraso da replicação.GLOBAL
: uma sessão em uma região secundária da AWS vê as alterações feitas por essa sessão. Também vê todas as alterações confirmadas da região principais da AWS e das outras regiões secundárias da AWS. Cada consulta pode aguardar por um período que varia de acordo com a quantidade de atraso da sessão. A consulta prossegue quando o cluster secundário está atualizado com todos os dados confirmados do cluster primário, a partir do momento em que a consulta foi iniciada.OFF
: o encaminhamento de gravação está desativado na sessão.
Para obter mais informações sobre todos os parâmetros envolvidos no encaminhamento de gravação, consulte Parâmetros de configuração para o encaminhamento de gravação no Aurora PostgreSQL.
Executar instruções de várias partes com o encaminhamento de gravação no Aurora PostgreSQL
Uma instrução DML pode consistir em várias partes, como uma instrução INSERT ... SELECT
ou uma instrução DELETE ... WHERE
. Nesse caso, a instrução inteira é encaminhada para o cluster primário e executada nele.
Parâmetros de configuração para o encaminhamento de gravação no Aurora PostgreSQL
Os parameter groups de cluster do Aurora incluem configurações para o recurso de encaminhamento de gravação. Como são parâmetros de cluster, todas as instâncias de banco de dados em cada cluster têm os mesmos valores para essas variáveis. Detalhes sobre esses parâmetros são resumidos na tabela a seguir, com notas de uso após a tabela.
Nome | Escopo | Type | Valor padrão | Valores válidos |
---|---|---|---|---|
apg_write_forward.connect_timeout
|
Sessão | segundos | 30 | 0–2147483647 |
apg_write_forward.consistency_mode |
Sessão | enum | Sessão |
SESSION , EVENTUAL , GLOBAL , OFF
|
apg_write_forward.idle_in_transaction_session_timeout
|
Sessão | milissegundos | 86400000 | 0–2147483647 |
apg_write_forward.idle_session_timeout
|
Sessão | milissegundos | 300000 | 0–2147483647 |
apg_write_forward.max_forwarding_connections_percent
|
Global | int | 25 | 1–100 |
O parâmetro apg_write_forward.max_forwarding_connections_percent
é o limite máximo em conexões de banco de dados que pode ser usado em consultas encaminhadas de leitores. Ele é expresso como uma porcentagem da configuração max_connections
para a instância de banco de dados de gravação no cluster primário. Por exemplo, se max_connections
for 800
e apg_write_forward.max_forwarding_connections_percent
for 10
, o gravador permitirá um máximo de 80 sessões encaminhadas simultaneamente. Essas conexões vêm do mesmo grupo de conexões gerenciado pela configuração max_connections
. Essa configuração se aplica somente ao cluster primário, quando, no mínimo, um cluster secundário tem o encaminhamento de gravação ativado.
Use as seguintes configurações no cluster secundário:
-
apg_write_forward.consistency_mode
: um parâmetro no nível de sessão que controla o grau de consistência de leitura no cluster secundário. Os valores válidos sãoSESSION
,EVENTUAL
,GLOBAL
ouOFF
. Por padrão, o valor é definido comoSESSION
. Definir o valor comoOFF
desativa o encaminhamento de gravação na sessão. Para saber mais sobre os níveis de consistência, consulte Isolamento e consistência para o encaminhamento de gravação no Aurora PostgreSQL. Esse parâmetro é relevante somente em instâncias de leitor de clusters secundários que têm o encaminhamento de gravação habilitado e que estão em um banco de dados global Aurora. apg_write_forward.connect_timeout
: o número máximo de segundos que o cluster secundário espera ao estabelecer uma conexão com o cluster primário antes de desistir. Um valor de0
significa esperar indefinidamente.apg_write_forward.idle_in_transaction_session_timeout
: o número de milissegundos que o cluster primário aguarda a atividade em uma conexão encaminhada de um cluster secundário que tem uma transação aberta antes de fechá-la. Se a sessão permanecer ociosa além desse período na transação, o Aurora encerrará a sessão. Um valor de0
desabilita o tempo limite.apg_write_forward.idle_session_timeout
: o número de milissegundos que o cluster primário aguarda a atividade em uma conexão encaminhada de um cluster secundário antes de fechá-la. Se a sessão permanecer ociosa além desse período, o Aurora encerrará a sessão. Um valor de0
desativa o tempo limite.
Métricas do Amazon CloudWatch para o encaminhamento de gravação no Aurora PostgreSQL
As métricas do Amazon CloudWatch a seguir se aplicam ao cluster primário quando você usa o encaminhamento de gravação em um ou mais clusters secundários. Essas métricas são todas medidas na instância de banco de dados de gravador no cluster primário.
Métrica do CloudWatch | Unidades e descrição |
---|---|
|
Contagem (por segundo). Número de instruções DML encaminhadas processadas a cada segundo por essa instância de banco de dados de gravador. |
|
Contagem. Número de sessões abertas nessa instância de banco de dados de gravação que processa consultas encaminhadas. |
|
Contagem. Número de sessões encaminhadas na instância de banco de dados de gravação. |
As métricas do CloudWatch a seguir se aplicam a cada cluster secundário. Essas métricas são medidas em cada instância de banco de dados de leitor em um cluster secundário com o encaminhamento de gravação habilitado.
Métrica do CloudWatch | Unidade e descrição |
---|---|
|
Contagem (por segundo). Número de confirmações em sessões encaminhadas por essa réplica a cada segundo. |
|
Milissegundos. Tempo médio de resposta, em milissegundos, de DMLs encaminhadas na réplica. |
|
Contagem (por segundo). Número de instruções DML encaminhadas processadas por segundo nessa réplica. |
|
Contagem. Número de sessões rejeitadas pelo cluster primário porque foi atingido o limite máximo de conexões ou o máximo de conexões de gravação e encaminhamento. |
|
Contagem. O número de sessões que estão usando o encaminhamento de gravação em uma instância de banco. |
|
Milissegundos. Tempo médio de espera, em milissegundos, que a réplica aguarda para ser consistente com a LSN do cluster primário. O grau em que a instância de banco de dados de leitura aguarda depende da configuração apg_write_forward.consistency_mode . Para obter mais informações sobre essa configuração, consulte Parâmetros de configuração para o encaminhamento de gravação no Aurora PostgreSQL. |
Eventos de espera para encaminhamento de gravação no Aurora PostgreSQL
O Amazon Aurora gera os seguintes eventos de espera quando você usa o encaminhamento de gravação com o Aurora PostgreSQL.
Tópicos
IPC:AuroraWriteForwardConnect
O evento IPC:AuroraWriteForwardConnect
ocorre quando um processo de back-end no cluster de banco de dados secundário está aguardando a abertura de uma conexão com o nó gravador do cluster de banco de dados primário.
Possíveis causas do maior número de esperas
Esse evento aumenta à medida que aumenta o número de tentativas de conexão do nó de leitura de uma região secundária no nó de gravação do cluster de banco de dados primário.
Ações
Reduza o número de conexões simultâneas de um nó secundário para o nó de gravação da região primária.
IPC:AuroraWriteForwardConsistencyPoint
O evento IPC:AuroraWriteForwardConsistencyPoint
descreve por quanto tempo uma consulta de um nó no cluster de banco de dados secundário aguardará até que os resultados das operações de gravação encaminhadas sejam replicados para a região atual. Esse evento só será gerado se o parâmetro do nível da sessão apg_write_forward.consistency_mode
estiver definido como um dos seguintes casos:
SESSION
: as consultas em um nó secundário aguardam os resultados de todas as alterações feitas nessa sessão.GLOBAL
: as consultas em um nó secundário aguardam os resultados das alterações feitas por essa sessão, além de todas as alterações confirmadas da região primária e de outras regiões secundárias no cluster global.
Para obter informações sobre as configurações do parâmetro apg_write_forward.consistency_mode
, consulte Parâmetros de configuração para o encaminhamento de gravação no Aurora PostgreSQL.
Possíveis causas do maior número de esperas
As causas comuns de tempos de espera mais longos incluem o seguinte:
Aumento do atraso na réplica, conforme medido pela métrica do Amazon CloudWatch
ReplicaLag
. Para obter mais informações sobre essa métrica, consulte Monitorar a replicação do Aurora PostgreSQL.Aumento da carga no nó de gravação da região primária ou no nó secundário.
Ações
Altere seu modo de consistência, dependendo dos requisitos da aplicação.
IPC:AuroraWriteForwardExecute
O evento IPC:AuroraWriteForwardExecute
ocorre quando um processo de back-end no cluster de banco de dados secundário está aguardando a conclusão de uma consulta encaminhada e a obtenção dos resultados no nó de gravação do cluster de banco de dados primário.
Possíveis causas do maior número de esperas
As causas típicas incluem:
Buscar um grande número de linhas no nó de gravação da região primária.
O aumento da latência da rede entre o nó secundário e o nó de gravação da região primária aumenta o tempo necessário para o nó secundário receber dados do nó de gravação.
O aumento da carga no nó secundário pode atrasar a transmissão da solicitação de consulta do nó secundário no nó de gravação da região primária.
O aumento da carga no nó de gravação da região primária pode atrasar a transmissão dos dados do nó de gravação para o nó secundário.
Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
Otimize as consultas para recuperar somente os dados necessários.
Otimize as operações de linguagem de manipulação de dados (DML) para modificar somente os dados necessários.
Se o nó secundário ou o nó de gravação da região primária estiver limitado pela CPU ou pela largura de banda da rede, considere alterá-lo para um tipo de instância com mais capacidade de CPU ou mais largura de banda de rede.
IPC:AuroraWriteForwardGetGlobalConsistencyPoint
O evento IPC:AuroraWriteForwardGetGlobalConsistencyPoint
ocorre quando um processo de back-end no cluster de banco de dados secundário que está usando o modo de consistência GLOBAL está esperando para obter o ponto de consistência global do nó de gravação antes de executar uma consulta.
Possíveis causas do maior número de esperas
As causas típicas incluem:
O aumento da latência da rede entre o nó secundário e o nó de gravação da região primária aumenta o tempo necessário para o nó secundário receber dados do nó de gravação.
O aumento da carga no nó secundário pode atrasar a transmissão da solicitação de consulta do nó secundário no nó de gravação da região primária.
O aumento da carga no nó de gravação da região primária pode atrasar a transmissão dos dados do nó de gravação para o nó secundário.
Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
Altere seu modo de consistência, dependendo dos requisitos da aplicação.
Se o nó secundário ou o nó de gravação da região primária estiver limitado pela CPU ou pela largura de banda da rede, considere alterá-lo para um tipo de instância com mais capacidade de CPU ou mais largura de banda de rede.
IPC:AuroraWriteForwardXactAbort
O evento IPC:AuroraWriteForwardXactAbort
ocorre quando um processo de back-end no cluster de banco de dados secundário está aguardando o resultado de uma consulta de limpeza remota. As consultas de limpeza são emitidas para retornar o processo ao estado apropriado após a interrupção de uma transação por gravação. O Amazon Aurora as executa porque um erro foi encontrado ou porque um usuário emitiu um comando ABORT
explícito ou cancelou uma consulta em execução.
Possíveis causas do maior número de esperas
As causas típicas incluem:
O aumento da latência da rede entre o nó secundário e o nó de gravação da região primária aumenta o tempo necessário para o nó secundário receber dados do nó de gravação.
O aumento da carga no nó secundário pode atrasar a transmissão da solicitação de consulta de limpeza do nó secundário no nó de gravação da região primária.
O aumento da carga no nó de gravação da região primária pode atrasar a transmissão dos dados do nó de gravação para o nó secundário.
Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
Investigue a causa da transação abortada.
Se o nó secundário ou o nó de gravação da região primária estiver limitado pela CPU ou pela largura de banda da rede, considere alterá-lo para um tipo de instância com mais capacidade de CPU ou mais largura de banda de rede.
IPC:AuroraWriteForwardXactCommit
O evento IPC:AuroraWriteForwardXactCommit
ocorre quando um processo de back-end no cluster de banco de dados secundário está aguardando o resultado de um comando de confirmação de transação encaminhada.
Possíveis causas do maior número de esperas
As causas típicas incluem:
O aumento da latência da rede entre o nó secundário e o nó de gravação da região primária aumenta o tempo necessário para o nó secundário receber dados do nó de gravação.
O aumento da carga no nó secundário pode atrasar a transmissão da solicitação de consulta do nó secundário no nó de gravação da região primária.
O aumento da carga no nó de gravação da região primária pode atrasar a transmissão dos dados do nó de gravação para o nó secundário.
Ações
Se o nó secundário ou o nó de gravação da região primária estiver limitado pela CPU ou pela largura de banda da rede, considere alterá-lo para um tipo de instância com mais capacidade de CPU ou mais largura de banda de rede.
IPC:AuroraWriteForwardXactStart
O evento IPC:AuroraWriteForwardXactStart
ocorre quando um processo de back-end no cluster de banco de dados secundário está aguardando o resultado de um comando de início de transação encaminhada.
Possíveis causas do maior número de esperas
As causas típicas incluem:
O aumento da latência da rede entre o nó secundário e o nó de gravação da região primária aumenta o tempo necessário para o nó secundário receber dados do nó de gravação.
O aumento da carga no nó secundário pode atrasar a transmissão da solicitação de consulta do nó secundário no nó de gravação da região primária.
O aumento da carga no nó de gravação da região primária pode atrasar a transmissão dos dados do nó de gravação para o nó secundário.
Ações
Se o nó secundário ou o nó de gravação da região primária estiver limitado pela CPU ou pela largura de banda da rede, considere alterá-lo para um tipo de instância com mais capacidade de CPU ou mais largura de banda de rede.