Estou tentando entender o processo de como o percona faz backup a quente. pelo que entendi, eles usam o mecanismo de recuperação de falhas innodb e executam as etapas a seguir.
- armazenar/lembrar iniciar LSN a partir de logs de redo
- copiar arquivos de dados
- execute LOCK BINLOG FOR BACKUP: para bloquear todas as operações que possam alterar a posição do log binário
- copiando os arquivos de log REDO e buscando as coordenadas binárias do log
- o xtrabackup concluído desbloqueará o log binário e as tabelas.
Quero entender qual é a função do LSN nos redo logs. Não podemos verificar diretamente a posição do log binário na etapa 1?
E o LSN final, ele não é usado em nenhum lugar do processo?
O LSN (Log Sequence Number) é análogo à posição do log binário, mas o redo log é um log diferente. Aplica-se apenas às páginas do InnoDB e contém diferenças físicas das páginas afetadas. Durante a recuperação de falhas, ele pode reconstruir páginas aplicando diferenças às páginas originais. Também pode detectar se uma alteração já foi aplicada a uma página, porque as páginas são carimbadas com o LSN. Ele lida com o caso de páginas que foram liberadas antes da falha, que não ocorrem necessariamente em qualquer ordem. Portanto, a partir do LSN anterior, não é necessário aplicar todas as alterações no redo log.
O log binário se aplica a tabelas de qualquer mecanismo de armazenamento e contém alterações lógicas. Pode conter eventos baseados em linhas ou eventos baseados em instruções. Não é usado para recuperação de falhas. Os logs binários são estritamente ordenados, portanto, se você usá-lo para sincronizar um banco de dados (por exemplo, replicação ou recuperação pontual), ele assumirá que todas as alterações serão aplicadas a partir da posição inicial fornecida.
Não há necessidade do Percona XtraBackup registrar o último LSN, porque a recuperação de falhas apenas processa todo o redo log até o final.
Não, isso não está correto. Lembre-se de que as transações não têm limite no número de linhas modificadas ou no número de alterações. Portanto, as alterações devem ser enfileiradas de alguma forma para permitir que o tamanho de uma transação seja grande.
No caso do log binário, as alterações são gravadas em um cache de log binário. Cada sessão recebe seu próprio cache de log binário. Por padrão, isso está na memória, mas se a transação for maior que o cache na memória, ela poderá ser copiada para o disco. À medida que você executa INSERT/UPDATE/DELETE, essas alterações são anexadas ao cache de log binário da respectiva sessão.
No COMMIT, todas as alterações são finalmente copiadas do cache do log binário da sessão para o log binário. Portanto, as alterações não aparecem no log binário até COMMIT.
O redo log é separado e é implementado apenas no mecanismo de armazenamento InnoDB. Ao executar INSERT/UPDATE/DELETE, as páginas de dados no buffer pool são modificadas. Nesse momento, essas alterações não confirmadas nas páginas também são gravadas no redo log. Como o redo log tem tamanho fixo, você pode fazer muitas alterações para caber no redo log e ele volta para o início. Para evitar a perda de alterações no caso de uma falha, as páginas modificadas no buffer pool devem ser descarregadas no disco antes que o redo log seja finalizado.
No COMMIT, o InnoDB não precisa copiar nenhum log ou liberar nenhuma página modificada. As páginas podem permanecer modificadas no buffer pool. Somente a transação é anotada como confirmada, gravando um pequeno registro no redo log. Portanto, se a recuperação de falhas for necessária, ele saberá quais páginas contêm alterações confirmadas. As páginas que não foram confirmadas no momento da falha são marcadas com um ID de transação que não é registrado como confirmado no redo log, portanto, essas páginas não precisam ser recuperadas.
O redo log é gravado continuamente, conforme você faz INSERT/UPDATE/DELETE, e é gravado durante COMMIT para marcar cada transação como confirmada. Mas o redo log não é lido, exceto durante a recuperação de falhas. Seu único propósito é reconstruir páginas modificadas no buffer pool.
O uso do LSN permite que a recuperação de falhas saiba por onde começar a processar o redo log. Por exemplo, se a maioria das páginas modificadas já foram liberadas no momento da falha, não há necessidade de processar o redo log antes da página mais antiga que ainda foi modificada no buffer pool. A recuperação de falhas pode pular diretamente para o LSN no redo log correspondente à página modificada mais antiga. Isso ajuda a recuperação de falhas a ser um pouco mais rápida.
O Percona XtraBackup usa o mesmo código de processamento de redo log, porque preparar um backup é semelhante à recuperação de falhas. Quando o Percona XtraBackup inicia a cópia de páginas para backup, algumas dessas páginas podem ter cópias modificadas no buffer pool. A cópia demora um pouco e algumas páginas podem ser liberadas ou modificadas durante esse tempo, à medida que o tráfego de consulta subsequente executa INSERT/UPDATE/DELETE. Quando o preparo do XtraBackup é executado, ele deve inspecionar todo o redo log até a página modificada mais antiga correspondente ao LSN no momento do início do backup, pois qualquer uma delas pode ser páginas "perdidas", ou seja, apenas a página do disco foi copiado para o backup, sem a versão modificada no buffer pool.
As páginas modificadas são liberadas continuamente para o tablespace. Leia https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool-flushing.html
Esperançosamente, a taxa de liberação de páginas modificadas é pelo menos rápida o suficiente para que o redo log não fique 100% cheio. O InnoDB não permite que páginas modificadas não liberadas existam no buffer pool se elas não forem recuperáveis pelos redo logs em caso de falha.
Se o log de redo atingir 100% cheio, as gravações no log de redo deverão ser pausadas até que alguma liberação de páginas possa ser alcançada. Isso significa que todas as ações INSERT/UPDATE/DELETE estão bloqueadas temporariamente. Você teria que sobrecarregar bastante sua instância do MySQL para chegar a esse estado (ou seja, carregá-la com uma taxa de gravação mais alta do que ela pode sustentar).