Na replicação primária-secundária, o mecanismo padrão COMMIT_ORDER determina a reaplicação paralela com base na possibilidade de efetuar commit em paralelo das transações na instância RDS primária. Isso limita o paralelismo de reaplicação à concorrência da instância primária. O WRITESET remove essa limitação ao detectar conflitos de transação no nível da linha, o que reduz o atraso de replicação entre as instâncias RDS primária e secundária.
Como o WRITESET funciona
Quando o COMMIT_ORDER está em uso, duas transações só podem ser reaplicadas em paralelo se for possível efetuar o commit delas em paralelo na instância RDS primária.
O WRITESET verifica se as linhas de dados modificadas por cada transação entram em conflito com as linhas modificadas por outras transações. Se não houver conflitos, as transações serão reaplicadas em paralelo na instância RDS secundária, independentemente de como o commit foi efetuado na instância RDS primária.
Versões compatíveis
É necessário que a instância RDS execute uma das seguintes versões do MySQL:
|
Versão do MySQL |
Versão secundária mínima do mecanismo |
|
MySQL 5.7 |
20211231 |
|
MySQL 8.0 |
20210930 |
Ative o WRITESET
Para obter instruções, consulte Modifique os parâmetros da instância e defina os três parâmetros a seguir.
transaction_write_set_extraction = XXHASH64
binlog_transaction_dependency_tracking = WRITESET
binlog_transaction_dependency_history_size = 500000O parâmetro binlog_transaction_dependency_history_size define o número máximo de linhas de dados armazenadas na memória para detecção de conflitos. Um valor maior rastreia mais linhas de dados e melhora o paralelismo.
Dependências de parâmetros
Os parâmetros binlog_transaction_dependency_tracking e transaction_write_set_extraction afetam-se mutuamente. Use as combinações válidas listadas abaixo. Combinações inválidas são bloqueadas.
|
binlog_transaction_dependency_tracking |
transaction_write_set_extraction |
|
|
|
|
|
|
Referência de parâmetros
binlog_transaction_dependency_tracking
Determina como as transações registradas nos logs binários são reaplicadas em paralelo na instância RDS secundária.
A reaplicação paralela multithread exige que replica_parallel_workers ou slave_parallel_workers seja maior que 0.
|
Atributo |
Valor |
|
Padrão |
|
|
Valores válidos |
|
|
Versões compatíveis |
MySQL 5.7 (versão secundária do mecanismo 20211231 e posterior), MySQL 8.0 (versão secundária do mecanismo 20210930 e posterior) |
|
Valor |
Descrição |
|
|
Determina as dependências com base na ordem de commit. Duas transações podem ser reaplicadas em paralelo na instância RDS secundária se for possível efetuar o commit delas em paralelo na instância RDS primária. Esse modo é afetado pelas configurações de paralelismo na instância RDS primária. |
|
|
Determina as dependências no nível da linha. Duas transações são reaplicadas em paralelo se não modificarem a mesma linha de dados de uma tabela com chave primária ou chave única. Esse modo não é afetado pelas configurações de paralelismo na instância RDS primária. |
|
|
As transações dentro da mesma sessão são reaplicadas sequencialmente. As transações de sessões diferentes seguem as mesmas regras do |
transaction_write_set_extraction
Especifica o algoritmo de hash usado para calcular o valor de hash de uma linha de dados. O valor de hash determina se transações diferentes modificam a mesma linha de dados.
|
Atributo |
Valor |
|
Padrão |
|
|
Valores válidos |
|
|
Versões compatíveis |
MySQL 5.7 (versão secundária do mecanismo 20211231 e posterior), MySQL 8.0 (versão secundária do mecanismo 20210930 e posterior) |
|
Valor |
Descrição |
|
|
Não calcula o valor de hash das linhas de dados. O |
|
|
Calcula o valor de hash das linhas de dados usando um algoritmo de hash de 64 bits. |
binlog_transaction_dependency_history_size
Especifica o número máximo de linhas de dados armazenadas na memória para detecção de conflitos.
|
Atributo |
Valor |
|
Valor recomendado |
|
|
Efeito |
Um valor maior rastreia mais linhas de dados e permite maior paralelismo. |
Quando o WRITESET se torna inválido
Em determinados cenários, o WRITESET reverte para o COMMIT_ORDER para detecção de conflitos de transação. Essa reversão não degrada o desempenho da reaplicação paralela na instância RDS secundária.
O WRITESET se torna inválido quando:
Execução de operações DDL
Commit de transações grandes
Modificação de tabelas com chaves estrangeiras
Existência de tabelas sem chave primária
Se houver atraso de replicação entre as instâncias RDS secundária e somente leitura, ative o WRITESET para reduzi-lo.
Referências
Use o recurso de diagnóstico de parâmetros para obter recomendações de otimização de parâmetros.
-
Documentação oficial do MySQL: