Noções básicas do MySQL (37) replicação mestre-escravo

1. Visão geral da replicação mestre-escravo

1.1 Como melhorar os recursos de simultaneidade do banco de dados

Além disso, as aplicações gerais são " 读多写少" para bancos de dados, o que significa que a pressão sobre o banco de dados para ler dados é relativamente alta.Uma ideia é usar uma solução de cluster de banco de dados para fazer 主从架构e executar 读写分离, o que também pode melhorar as capacidades de processamento simultâneo do base de dados. Mas nem todas as aplicações precisam configurar uma arquitetura mestre-escravo para o banco de dados, afinal, configurar a arquitetura em si é caro.

Se nosso objetivo é melhorar a eficiência do alto acesso simultâneo ao banco de dados, então a primeira coisa a considerar é como 优化SQL和索引esse método é simples e eficaz; a segunda é adotar 缓存的策略, como usar Redis para salvar dados importantes em um in- banco de dados de memória para melhorar a eficiência da leitura; finalmente, a única maneira de usar o banco de dados 主从架构é separar a leitura e a escrita.

1.2 O papel da replicação mestre-escravo

O projeto de sincronização mestre-escravo pode não apenas melhorar o rendimento do banco de dados, mas também ter os três aspectos a seguir.
第1个作用：读写分离

第2个作用就是数据备份。
第3个作用是具有高可用性。

2. Princípio da replicação mestre-escravo

SlaveA sincronização dos dados será feita a partir Masterda leitura binlog.

2.1 Análise de princípios

三个线程
Na verdade, o princípio da sincronização mestre-escravo é baseado no log binário para sincronização de dados. Durante o processo de replicação mestre-escravo, 3 个线程as operações serão baseadas em um thread da biblioteca principal e dois threads da biblioteca escrava.

二进制日志转储线程(Thread de despejo Binlog) é um thread da biblioteca principal. Quando o thread da biblioteca escrava está conectado, a biblioteca principal pode enviar o log binário para a biblioteca escrava. Quando a biblioteca principal ler o evento (Evento), ele estará no Binlog. Após a conclusão da leitura, o bloqueio será liberado 加锁.

从库 I/O 线程Ele se conectará à biblioteca principal e enviará uma solicitação à biblioteca principal para atualizar o Binlog. Neste momento, o thread de E/S da biblioteca escrava pode ler a parte de atualização do Binlog enviada pelo thread de dump do log binário da biblioteca principal e copiá-la para o log de retransmissão local (relay log).

从库 SQL 线程O log de retransmissão na biblioteca escrava será lido e os eventos no log serão executados para manter os dados da biblioteca escrava sincronizados com a biblioteca mestre.

复制三步骤

Etapa 1: MasterRegistrar operações de gravação no log binário ( binlog).

Passo 2: SlaveCopie Masteros eventos do log binário para seu log de retransmissão ( relay log);

Etapa 3: Slaverefaça os eventos no log de retransmissão e aplique as alterações ao seu próprio banco de dados. A replicação do MySQL é assíncrona e serializada, e 接入点a replicação começa após a reinicialização.

复制的问题

O maior problema com replicação:延时

2.2 Princípios básicos de replicação

• Slaveapenas um de cadaMaster
• Cada um Slavesó pode ter um ID de servidor exclusivo
• Cada um Masterpode ter váriosSlave

3. Construção de uma arquitetura mestre e uma arquitetura escrava

Um 主机é usado para processar tudo 写请求e o outro 从机é responsável por tudo 读请求. O diagrama da arquitetura é o seguinte:

3.1 Preparação

1. Prepare 2台a máquina virtual CentOS
2. O MySQL precisa ser instalado em cada máquina virtual (pode ser MySQL8.0)

3.2 Arquivo de configuração do host

Recomenda-se que a versão do mysql seja consistente e execute como um serviço em segundo plano.Todos os itens de configuração do mestre e do escravo são configurados no [mysqld]nó e todos estão em letras minúsculas. A configuração específica dos parâmetros é a seguinte:

• obrigatório

#[必须]主服务器唯一ID
server-id=1
#[必须]启用二进制日志,指名路径。比如：自己本地的路径/log/mysqlbin
log-bin=atguigu-bin

• Opcional

#[可选] 0（默认）表示读写（主机），1表示只读（从机）
read-only=0
#设置日志文件保留的时长，单位是秒
binlog_expire_logs_seconds=6000
#控制单个二进制日志大小。此参数的最大和默认值是1GB
max_binlog_size=200M
#[可选]设置不要复制的数据库
binlog-ignore-db=test
#[可选]设置需要复制的数据库,默认全部记录。比如：binlog-do-db=atguigu_master_slave
binlog-do-db=需要复制的主数据库名字
#[可选]设置binlog格式
binlog_format=STATEMENT

binlog格式设置：
Formato 1: STATEMENT模式(replicação baseada em instrução SQL (SBR))

binlog_format=STATEMENT

Cada instrução SQL que modifica dados será registrada no log binário. Este é o formato de log binário padrão.

• Vantagens do SBR:
  • Longa história e tecnologia madura
  • Não há necessidade de registrar alterações em cada linha, o que reduz a quantidade de logs do binlog e torna o arquivo menor.
  • O log binário contém todas as informações de alteração do banco de dados, que podem ser usadas para auditar a segurança do banco de dados.
  • binlog pode ser usado para restauração em tempo real, não apenas para replicação
  • As versões mestre e escravo podem ser diferentes e a versão do servidor escravo pode ser superior à versão do servidor mestre.
• Desvantagens do SBR:
  • Nem todas as instruções UPDATE podem ser replicadas, especialmente se contiverem operações indeterminadas.
• Instruções usando as seguintes funções não podem ser copiadas: LOAD_FILE(), UUID(), USER(), FOUND_ROWS(), SYSDATE() (a menos que a opção --sysdate-is-now esteja habilitada na inicialização)
  • INSERT ... SELECT gerará mais bloqueios em nível de linha que RBR
  • Ao copiar um UPDATE que requer uma varredura completa da tabela (nenhum índice é usado na instrução WHERE), são necessários mais bloqueios em nível de linha do que RBR.
  • Para tabelas InnoDB com campos AUTO_INCREMENT, a instrução INSERT bloqueia outras instruções INSERT.
  • Para algumas instruções complexas, o consumo de recursos no servidor escravo será mais grave e, no modo RBR, afetará apenas o registro alterado.
  • Se ocorrerem erros ao executar instruções complexas, mais recursos serão consumidos.
  • A tabela de dados deve ser quase consistente com o servidor principal, caso contrário poderá causar erros de replicação.

Formato 2: ROW模式(replicação baseada em linha (RBR))

binlog_format=ROW

O MySQL versão 5.1.5 apenas começou a suportar isso, ele não registra as informações de contexto de cada instrução SQL, mas apenas registra quais dados foram modificados e quais foram as modificações.

• Vantagens do RBR:
  • Qualquer situação pode ser copiada, o que é melhor para replicação 安全可靠. (Por exemplo: não haverá problema se procedimentos armazenados, funções, chamadas de gatilho e gatilhos não puderem ser copiados corretamente sob certas circunstâncias)
  • Na maioria dos casos, a replicação será muito mais rápida se a tabela no servidor escravo tiver uma chave primária.
  • Replique os seguintes tipos de instruções com menos bloqueios de linha: INSERT ... SELECT, INSERT contendo um campo AUTO_INCREMENT, instruções UPDATE ou DELETE sem condições ou sem modificar muitos registros
  • Menos bloqueios ao executar instruções INSERT, UPDATE, DELETE
  • 多线程É possível realizar replicação do servidor usando
• Desvantagens do RBR:
  • binlog é muito maior
  • Durante a reversão complexa, o log binário conterá uma grande quantidade de dados.
  • Quando a instrução UPDATE é executada no servidor principal, todos os registros alterados serão gravados no log binário, mas o SBR os gravará apenas uma vez, o que levará a problemas frequentes de gravação simultânea no log binário.
  • Não é possível ver quais instruções foram copiadas do binlog

Formato 2: MIXED模式(replicação de base mista (MBR))

binlog_format=MIXED

A partir da versão 5.1.8, o MySQL fornece formato misto, que na verdade é uma combinação de instrução e linha.

No modo Misto, as modificações gerais de instruções usam o formato de instrução para salvar o log binário. Por exemplo, algumas funções e instruções não podem concluir a operação de replicação mestre-escravo, portanto, o log binário é salvo no formato de linha.

O MySQL irá distinguir a forma de log a ser registrada com base em cada instrução SQL específica executada, ou seja, escolher uma entre Instrução e Linha.

3.3 Arquivo de configuração do escravo

É necessário que todos os itens de configuração do mestre e do escravo estejam configurados no campo , e todos estejam em letras minúsculas my.cnf.[mysqld]

• obrigatório

  #[必须]从服务器唯一ID
  server-id=2
  

• Opcional

  #[可选]启用中继日志
  relay-log=mysql-relay
  

Reinicie o serviço mysql em segundo plano para que a configuração tenha efeito.

Nota: Tanto a máquina mestre quanto a escrava desligam o
serviço de firewall iptables stop #CentOS 6
systemctl stop firewalld.service #CentOS 7

3.4 Host: Crie uma conta e autorize-a

#在主机MySQL里执行授权主从复制的命令
GRANT REPLICATION SLAVE ON *.* TO 'slave1'@'从机器数据库IP' IDENTIFIED BY 'abc123';
#5.5,5.7

注意：如果使用的是MySQL8，需要如下的方式建立账户，并授权slave：

CREATE USER 'slave1'@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE ON *.* TO 'slave1'@'%';
#此语句必须执行。否则见下面。
ALTER USER 'slave1'@'%' IDENTIFIED WITH mysql_native_password BY '123456';
flush privileges;

Nota: Ao executar show slave status\G no escravo, um erro é relatado: Last_IO_Error: erro ao conectar ao mestre '[email protected]:3306' - tempo de repetição: 60 tentativas: 1 mensagem: Plugin de autenticação 'caching_sha2_password' relatado erro: a autenticação requer conexão segura.

Consultar o status do Mestre e registrar os valores de Arquivo e Posição.

show master status;

• Registre os valores de Arquivo e Posição

Nota: Depois de executar esta etapa 不要再操作主服务器MySQL, evite que o valor do status do servidor mestre seja alterado.

3.5 Slave: Configure o host que precisa ser copiado

步骤1: Copie o comando host da máquina escrava

CHANGE MASTER TO
MASTER_HOST='主机的IP地址',
MASTER_USER='主机用户名',
MASTER_PASSWORD='主机用户名的密码',
MASTER_LOG_FILE='mysql-bin.具体数字',
MASTER_LOG_POS=具体值;

Exemplo:

CHANGE MASTER TO
MASTER_HOST='192.168.1.150',MASTER_USER='slave1',MASTER_PASSWORD='123456',MASTER_LOG_FILE='atguigu-bin.000007',MASTER_LOG_POS=154;

步骤2：

#启动slave同步
START SLAVE;

Se um erro for relatado:

Você pode executar as seguintes operações para excluir as informações anteriores do relay_log. Em seguida, execute novamente a instrução CHANGE MASTER TO....

mysql> reset slave; #删除SLAVE数据库的relaylog日志文件，并重新启用新的relaylog文件

Em seguida, verifique o status da sincronização:

SHOW SLAVE STATUS\G;

Se os dois parâmetros acima forem Sim, significa que a configuração mestre-escravo foi bem-sucedida!

A seguinte situação explícita está incorreta. As possíveis razões para o erro são:

1. 网络不通
2. 账户密码错误
3. 防火墙
4. mysql配置文件问题
5. 连接服务器时语法
6. 主服务器mysql权限

3.6 Teste

O host cria uma nova biblioteca, uma nova tabela e insere registros e as cópias escravas:

CREATE DATABASE master_slave;
CREATE TABLE mytbl(id INT,NAME VARCHAR(16));
INSERT INTO mytbl VALUES(1, 'zhang3');
INSERT INTO mytbl VALUES(2,@@hostname);

3.7 Parar a sincronização mestre-escravo

• Pare o comando de sincronização mestre-escravo:

  stop slave;
  

• Como reconfigurar o mestre e o escravo. Se
  você interromper a função de replicação do servidor escravo, será necessário reconfigurar o mestre e o escravo novamente. Caso contrário, será reportado o seguinte erro:
  
  A reconfiguração do mestre e do escravo precisa ser executada na máquina escrava:

  stop slave;
  reset master; #删除Master中所有的binglog文件，并将日志索引文件清空，重新开始所有新的日志文件(慎用)
  

3.8 Acompanhamento

搭建主从复制：双主双从

4. Problemas de consistência de dados de sincronização

主从同步的要求：

• Os dados no banco de dados de leitura e no banco de dados de gravação são consistentes (eventualmente consistentes);

• Os dados de gravação devem ser gravados na biblioteca de gravação;

• Os dados de leitura devem ir para a biblioteca de leitura (não necessariamente);

4.1 Compreendendo o problema de atraso mestre-escravo

O conteúdo da sincronização mestre-escravo é o log binário, que é um arquivo.Durante o processo de transmissão da rede, haverá um atraso mestre-escravo (como 500ms), que pode fazer com que os dados lidos pelo usuário da biblioteca escrava não ser o mais recente. Dados, ou seja,
inconsistência .

4.2 Causas do problema de atraso mestre-escravo

Quando a rede está normal, o tempo necessário para que o log seja transferido do banco de dados mestre para o banco de dados escravo é muito curto, ou seja, o valor de T2-T1 é muito pequeno. Ou seja, em condições normais de rede, a principal fonte de atraso entre os bancos de dados primário e secundário é a diferença de tempo entre o banco de dados secundário receber o log binário e executar a transação.

主备延迟最直接的表现是，从库消费中继日志（relay log）的速度，比主库生产binlog的速度要慢. Causa de:

1. O desempenho da máquina do banco de dados escravo é pior do que o do banco de dados principal

2. Há muita pressão na biblioteca escrava

3. Execução de assuntos importantes

举例1: Muitos dados são excluídos com uma instrução delete de uma só vez.Conclusão
: Ao excluir dados posteriormente, é necessário controlar a quantidade de dados excluídos por cada transação e dividi-los em múltiplas exclusões.

举例2: Muitos dados são inseridos usando insert...select de uma só vez

举例3: DDL de tabela grande.
Por exemplo, se levar 10 minutos para adicionar um campo a uma tabela de 500 W no banco de dados principal, também levará 10 minutos no nó escravo.

4.3 Como reduzir o atraso mestre-escravo

Se quiser reduzir o tempo de atraso mestre-escravo, você pode usar os seguintes métodos:

1. Reduza a probabilidade de simultaneidade de grandes transações multithread e otimize a lógica de negócios
2. Para otimizar SQL, evitar SQL lento e reduzir operações em lote, é recomendado escrever scripts na forma de update-sleep.
3. Melhore a configuração da máquina de banco de dados escrava e reduza a diferença de eficiência entre o log binário de gravação do banco de dados mestre e o log binário de leitura do banco de dados escravo.
4. Tente usar links curtos, ou seja, a distância entre o banco de dados mestre e o servidor de banco de dados escravo deve ser a mais curta possível para aumentar a largura de banda da porta e reduzir o atraso da rede na transmissão do log binário.
5. As leituras de negócios que exigem requisitos em tempo real são forçadas a ir para o banco de dados principal, e o banco de dados escravo é usado apenas para recuperação de desastres e backup.

4.4 Como resolver problemas de consistência

Se os dados operados estiverem armazenados no mesmo banco de dados, ao atualizar os dados, você pode adicionar um bloqueio de gravação ao registro, para que não ocorra inconsistência de dados durante a leitura. 备份Mas, neste momento , o papel da biblioteca escrava é 读写分离compartilhar 读压力o papel da biblioteca principal.

No caso da separação leitura-gravação, o problema de inconsistência de dados na sincronização mestre-escravo é resolver 数据复制方式o problema entre mestre e escravo.Se 从弱到强dividido de acordo com a consistência dos dados, existem os três métodos de replicação a seguir.

Método 1: replicação assíncrona

Método 2: replicação semissíncrona

Método 3: Nem a replicação assíncrona nem a replicação semissíncrona na replicação de grupo
podem, em última análise, garantir a consistência dos dados. A replicação semissíncrona determina se deve ser devolvida ao cliente, julgando o número de respostas do banco de dados. Embora a consistência dos dados seja melhor que a replicação assíncrona Houve melhora, mas ainda não consegue atender cenários que exigem alta consistência de dados, como na área financeira. O MGR compensa muito bem as deficiências desses dois modos de replicação.

Tecnologia de replicação de grupo, conhecida como MGR (MySQL Group Replication). É uma nova tecnologia de replicação de dados lançada pelo MySQL na versão 5.7.17.Esta tecnologia de replicação é baseada na replicação da máquina de estado do protocolo Paxos.

MGR 是如何工作的

Primeiro, formamos vários nós em um grupo de replicação. Nesse 执行读写（RW）事务momento, é necessário o acordo da camada de protocolo de consistência (camada de consenso), ou seja, se as transações de leitura e gravação quiserem ser enviadas, elas devem passar pela "maioria de pessoas" no grupo (correspondente ao acordo do Nó (correspondente ao Nó), a maioria deles significa que o número de nós acordados precisa ser maior que (N/2+1), para que o envio possa ser realizado, em vez do que o iniciador original ter a palavra final. Para 只读（RO）事务, nenhuma aprovação do grupo é necessária, apenas COMMIT diretamente.

Um grupo de replicação consiste em vários nós, cada um dos quais mantém sua própria cópia dos dados e implementa mensagens atômicas e mensagens ordenadas globais na camada de protocolo de consistência para garantir a consistência dos dados dentro do grupo.

O MGR traz o MySQL para a era da forte consistência de dados, o que é uma inovação que marcou época. Uma das razões importantes é que o MGR é baseado no protocolo Paxos. O algoritmo Paxos foi proposto por Leslie Lamport, vencedor do Prêmio Turing de 2013, em 1990. Você pode pesquisar o mecanismo de tomada de decisão desse algoritmo. Na verdade, o algoritmo Paxos tem sido amplamente utilizado como algoritmo de consenso distribuído desde que foi proposto.Por exemplo, o ZooKeeper do Apache também é implementado com base no Paxos.

5. Extensão do conhecimento

Na configuração da arquitetura mestre-escravo, se quisermos adotar uma estratégia de separação leitura-gravação, 自己编写程序também podemos 第三方的中间件implementá-la por meio de .

• A vantagem de escrever o programa você mesmo é que ele é mais independente. Podemos julgar quais consultas executar no banco de dados escravo. Para altos requisitos de tempo real, também podemos considerar quais consultas podem ser executadas no banco de dados principal. Ao mesmo tempo, o programa se conecta diretamente ao banco de dados, reduzindo a camada de middleware, o que equivale a reduzir a perda de desempenho.
• O método middleware tem vantagens óbvias, é poderoso e fácil de usar. No entanto, haverá alguma perda de desempenho devido à adição de uma camada de middleware entre o cliente e o banco de dados, e o middleware comercial também tem custos de uso. Também podemos considerar a adoção de algumas excelentes ferramentas de código aberto.

① CobarPertence ao grupo de negócios B2B do Alibaba. Começou em 2008 e atua no Alibaba há mais de 3 anos. Assumiu o esquema de mais de 3.000 bancos de dados MySQL e o cluster processa mais de 5 bilhões de solicitações SQL on-line por dia. Devido à renúncia do patrocinador da Cobar, a Cobar deixou de manter.

② MycatA comunidade de código aberto conduziu o desenvolvimento secundário com base no Alibaba cobar, que resolveu os problemas do cobar e adicionou muitas
funções novas. o aluno supera o mestre.

③ OneProxyBaseado na ideia de proxy oficial do MySQL e desenvolvido em linguagem c, OneProxy é um middleware comercial pago
. Abandonou alguns recursos para focar 性能和稳定性上.

④ kingshardDesenvolvido por uma pequena equipe utilizando a linguagem Go, ainda precisa de desenvolvimento e melhoria contínua.

⑤É Vitessutilizado pela produção do Youtube e a estrutura é muito complexa. O protocolo nativo MySQL não é suportado, use 需要大量改造成本.

⑥ AtlasFoi reescrito pela equipe 360 ​​com base no proxy mysql. A função precisa ser melhorada e é instável sob alta simultaneidade.

⑦ MaxScaleé o middleware desenvolvido por mariadb (uma versão mantida pelo autor original do MySQL)

⑧ MySQLRouteé o middleware lançado pela empresa oficial Oracle MySQL

Comutação ativa/em espera:

• Comutação ativa
• Comutação passiva
• Como determinar se há algum problema com o banco de dados principal? Como resolver inconsistências de dados no processo?