[Banco de dados] Vários registros no MySQL

Vários registros no MySQL

Prefácio

Existem vários arquivos de log no MySQL, a saber:

• redo log redo log
• desfazer log de rollback
• log binário binlog
• log de erros log de erros
• log de consulta lenta log de consulta lenta
• log geral log geral de consulta
• relay log

De acordo com o grau de foco, aqui está uma breve introdução ao binlog, redo log e undo log

Vamos ver uma imagem primeiro. Depois de ler o artigo, você pode revisitar esta imagem. Você também pode desenhá-la e adicioná-la mais completa:

binlog

Os dados de sincronização mestre-escravo geralmente são obtidos por meio dele. É um log binário que não é mantido pela camada do servidor MySQL. É um log completamente diferente do log de redo / undo no mecanismo InnoDB. É usado principalmente para registrar instruções SQL que atualizam dados MySQL ou que se escondem na ocorrência de atualizações, e usar "transações" "O formulário é salvo no disco

As principais funções são as seguintes:

• Replicação: a replicação mestre-escravo do MySQL inicia o binlog no lado mestre, e o mestre passa seu log binário para escravos e o reproduz para atingir o objetivo de dados mestre-escravo consistentes
• Recuperação de dados: recuperar dados por meio da ferramenta MySQLbinLog
• Dados de backup incrementais

Pontos de conhecimento:

• O Binlog não grava instruções que não modificam os dados, como Selecionar ou Mostrar.
• binlog irá reescrever a senha no log para garantir que ela não apareça em texto simples
• Versões posteriores ao MySQL8 podem optar por criptografar o binlog
• Tempo de gravação específico: quando a transação é enviada, o banco de dados grava o cache binlog no arquivo binlog, mas não executa a operação fsync (), ou seja, apenas grava o conteúdo do arquivo no cache do sistema operacional e, em seguida, determina se deve execute-o de acordo com a configuração fsync.
• Tempo de exclusão: o tempo de retenção é configurado pelo parâmetro expire_logs_days, o que significa que os arquivos de log inativos serão excluídos automaticamente após o tempo de geração exceder o número de dias configurado por expire_logs_days.

formato:

O log binlog tem três formatos: linha, instrução e misto. Ele pode
set global binlog_format='ROW/STATEMENT/MIXED'
ser modificado por meio do arquivo de configuração my.cnf e o show variables like 'binlog_format'formato binlog pode ser visualizado usando comandos.

Formato de
linha O formato de linha salva apenas os detalhes modificados do registro e não registra as informações relacionadas ao contexto da instrução SQL. A nova versão do MySQL tem como padrão o formato de linha.
1. Suas vantagens são: ele
pode registrar os detalhes de modificação de cada linha de dados de forma muito clara, sem necessidade de registrar informações de contexto, e o problema de procedimento armazenado, função ou chamada de gatilho acionada em certas circunstâncias específicas e não pode ser copiada corretamente. A situação pode ser replicada e pode acelerar a eficiência da reprodução de logs do banco de dados e garantir a consistência dos dados do banco de dados.
2. A desvantagem é:
como todas as instruções executadas são registradas no log com os detalhes de modificação de cada linha, uma grande quantidade de conteúdo de log pode ser gerada e haverá mais conteúdo de interferência. Por exemplo, se uma instrução de atualização altera vários registros, cada modificação no log binário será registrada, o que causará uma grande quantidade de logs binlog, especialmente ao executar instruções como alter table, devido a mudanças na estrutura da tabela, cada os registros são alterados, então cada registro da tabela será registrado no log, o que equivale a reconstruir a tabela.

Formato da instrução
Cada sql que modificará os dados será registrado no log bin.
1. As vantagens são:
só precisa registrar os detalhes da instrução executada e o contexto, evite registrar as alterações de cada linha, no caso de alguns registros de modificação mais do que o formato da linha pode reduzir muito a quantidade de log binlog, salve IO e melhorar o desempenho.
Também pode ser usado para restauração em tempo real.
As versões mestre e escravo podem ser diferentes e a versão do servidor escravo pode ser superior à versão do servidor mestre.
2. A desvantagem é:
para garantir que a instrução sql possa ser executada corretamente no escravo, as informações de contexto devem ser registradas para garantir que todas as instruções possam obter o mesmo resultado quando executadas no escravo e no mestre.
Além disso, durante a replicação mestre-escravo, existem algumas funções como dormir e o processo de armazenamento de erros que aparecem na inconsistência do resultado mestre da última vez no escravo. Comparado com os detalhes de mudança de cada linha registrada por linha, essa inconsistência nunca será acontecer.

Formato misto

É uma mistura dos dois formatos acima.
Após a comparação anterior, você pode descobrir que Row e Statement têm suas próprias vantagens.Se você puder escolher entre as instruções SQL, poderá ter melhor desempenho e experiência. Misto é uma combinação de duas formas.

Replicação mestre-escravo
Uma das funções mais importantes do MySQL durante a replicação, a alta disponibilidade, balanceamento de carga e separação de leitura e gravação do cluster do MySQL são todos baseados na replicação. As etapas de cópia são as seguintes:
1. O mestre registra as alterações de dados no log bin.
2. O processo IO no Slave se conecta ao Mestre e solicita o conteúdo do log do local especificado do arquivo de log especificado ou da posição inicial 3. Após o
Mestre receber a solicitação do processo IO do Slave, o Processo IO responsável por copiar de volta para a base As informações de log após as informações de solicitação irem para o local especificado apenas do log, são retornadas ao processo IO do Slave. Além das informações contidas no log, as informações retornadas também incluem o nome do arquivo binlog e a localização do binlog em que as informações retornadas chegaram ao Mestre.
4. Depois que o processo Slave IO recebe as informações, ele adiciona o conteúdo do log recebido ao final do arquivo relaylog no lado Slave, por sua vez, e registra o nome do arquivo e a localização do binlog no lado Master que foram lidos o arquivo masterinfo para a próxima vez Quando você estiver sozinho, pode limpar o conteúdo do log para informar ao Master de qual posição em um log bin deve iniciar.
5. Depois que o processo SQL do Slave detecta que o conteúdo recém-adicionado é adicionado ao relaylog, ele irá analisar imediatamente o conteúdo do relaylog para se tornar um conteúdo executável quando for executado diretamente no lado Master, e executá-lo em si mesmo.

desfazer log 和 refazer log

O log de desfazer e o log de redo não são logs no nível do banco de dados MySQL, mas logs do mecanismo de armazenamento InnoDB. As funções dos dois estão intimamente relacionadas.O isolamento da transação é realizado pelo bloqueio, e a atomicidade, consistência e durabilidade são concluídas pelo log de redo e undo log do banco de dados. O log de redo, também conhecido como log de redo, é usado para garantir a durabilidade das transações, e o log de undo é usado para garantir a atomicidade das transações e MVCC.

tronco de rodo

• Contém duas partes: buffer de redo log volátil e arquivo de redo log persistente
• Armazenado no arquivo de log de redo (arquivo de log de redo)
• Manter a persistência
• Operações de página

A função é a mesma da maioria dos bancos de dados relacionais. O InnoDB registra as alterações físicas no arquivo de dados e garante que o log seja sempre o primeiro, que é o chamado WAL, que garante que o redo log anterior foi gravado no disco antes do arquivo de dados é persistido. Como o redolog é escrito sequencialmente em blocos, o desempenho é melhor.

O redo log consiste em duas partes: uma é o buffer de redo log na memória, que é fácil de perder, e a outra é o arquivo de redo log, que é persistente. O log de redo registra alterações nas operações de transação e registra os valores modificados dos dados, independentemente de a transação ter sido confirmada ou não.

O processo de escrita é que quando uma instrução é executada, o motor InnoDB irá escrever um novo registro no log de redo log, e então atualizar a memória. Após a atualização ser completada, mesmo se a instrução for executada, ela ficará ociosa ou como set A estratégia de atualização atualiza o conteúdo do log de redo no disco.

O armazenamento do log de redo é armazenado em blocos e o tamanho de cada bloco é de 512 bytes. O mesmo tamanho do setor do disco, o que pode garantir que a gravação do bloco seja uma operação atômica

desfazer log

• Dividido em inserir log de desfazer (inserir, inserir só é visível para sua própria transação e não tem efeito em outras transações) e atualizar o log de desfazer (atualizar / excluir)
• Armazenado no segmento de desfazer (segmento) no banco de dados
• Para reversão
• Usado para MVCC (para alcançar leitura sem bloqueio), ao ler uma linha de registros, se já estiver ocupada por outras transações, a versão anterior é lida por desfazer
• Manter a atomicidade
• Operação de linha (reverter registros de linha para uma determinada versão)
• Desfazer é o log lógico, que apenas restaura a lógica do banco de dados antes de executar a instrução ou transação.

Quando os dados são modificados, não apenas o refazer é registrado, mas o desfazer correspondente também é registrado. Se a transação falhar ou reverter devido a alguns motivos, você pode usar o desfazer para reverter.

O log de desfazer e refazer o registro do log físico não é o mesmo, é um log lógico. Pode-se considerar que quando um registro é excluído, um registro de inserção correspondente será gravado no log de undo, e vice-versa, quando um registro for atualizado, ele gravará um registro de atualização correspondente.

Às vezes, quando aplicado ao controle de versão de linha, também é obtido por meio do log de desfazer: quando uma leitura de linha é bloqueada por outras transações, pode analisar os dados anteriores do registro de linha do log de desfazer e fornecer as informações de versão de linha, permitindo aos usuários para obter uma leitura consistente sem bloqueio.

O log de desfazer é registrado por segmento e cada operação de desfazer ocupa um segmento de log de desfazer durante a gravação.

Além disso, o log de desfazer também gerará o log de redo, porque o log de desfazer também precisa obter proteção persistente.

Quando a transação é confirmada, o InnoDB não deleta o log de desfazer imediatamente, porque o log de desfazer pode ser usado mais tarde. Por exemplo, quando o nível de isolamento é lido repetidamente, a transação lê a última versão da linha confirmada quando a transação é iniciada, como contanto que a transação Se não terminar, a versão da linha não pode ser excluída, ou seja, o log de desfazer não pode ser excluído.

Depois que a transação é confirmada, o log de desfazer não pode ser excluído imediatamente, mas é colocado na lista vinculada para ser limpo. O thread de limpeza determina se há outras transações usando as informações da versão anterior da transação anterior na tabela de desfazer segmento para determinar se o desfazer pode ser limpo Espaço de log para log.

Antes do MySQL 5.7, o undo log era armazenado em um espaço de tabela compartilhado, então é possível aumentar muito a ocupação do espaço de tabela.A partir do 5.7, ele pode ser armazenado em um espaço de tabela separado por meio de opções de configuração.

Anexo:
Vários parâmetros de configuração do log de consulta lenta:
slow_query_log consulta lenta no estado
slow_query_log_file local de armazenamento do log de consulta lenta (este diretório precisa da permissão gravável da conta de execução do MySQL, geralmente definido como diretório de armazenamento de dados MySQL)
long_query_time Quantos segundos a consulta excede o registro
log_queries_not_using_indexes: índice não utilizado também registrou uma consulta para o log de consulta lenta (opcional) parâmetros podem ser modificados através do arquivo de configuração, também pode ser definido pela palavra-chave sET no banco de dados.