Conceitos
O log é o banco (Aurora)
Intuição
Imagine um caderno de contabilidade em que você só anota cada mudança, uma linha atrás da outra, sem nunca reescrever as páginas antigas. O saldo atual de qualquer conta pode ser reconstruído relendo as anotações, então o caderno de anotações é a verdade, e qualquer resumo que você mantenha em outra folha é só uma conveniência que pode ser refeita a qualquer momento. Se várias pessoas guardam cópias desse caderno, basta enviar a elas as novas linhas, e não folhas inteiras recopiadas.
Como funciona
No Aurora, a camada do banco envia pela rede apenas registros de redo log: nenhuma página de dados é escrita, nem em background, nem em checkpoint, nem na expulsão do cache. A camada de armazenamento recebe esses registros e aplica o log para materializar as páginas, continuamente ou sob demanda; do ponto de vista da correção, as páginas materializadas são só um cache, e o log é o banco de dados. Os registros são agrupados em lotes por Protection Group e enviados às 6 cópias em 3 AZs, e o banco espera confirmação de um quórum de escrita de 4/6; só receber e persistir o registro fica no caminho síncrono, o resto é assíncrono. Em vez de 2PC, cada registro recebe um LSN crescente, e o armazenamento calcula o VDL, até onde o volume é durável; o commit é assíncrono e a transação só é confirmada ao cliente quando o VDL alcança o seu commit LSN. Leituras em operação normal vão a um único segmento já completo até o read-point, sem quórum de leitura. Na recuperação não há reaplicação do log desde um checkpoint: o banco consulta um quórum de leitura de cada PG, recalcula o VDL e trunca os registros acima dele. A mesma ideia de um log ordenado, replicado e confirmado por maioria aparece no Raft, onde uma entrada é comprometida ao ser replicada em maioria; no Aurora, a ordem vem dos LSNs emitidos pelo único writer, e a durabilidade vem do quórum de 4/6 de cada PG, sem 2PC.
Na prática
O paper mostra o efeito prático: no teste SysBench write-only de 100 GB, o Aurora sustentou 35 vezes mais transações que o MySQL espelhado, com 0,95 I/O por transação contra 7,4, mesmo amplificando as escritas seis vezes. A recuperação costuma levar menos de 10 segundos e as réplicas de leitura, que compartilham o mesmo volume, ficaram a 5,38 ms de defasagem a 10.000 escritas/s contra 300 s no MySQL. Considere esse desenho quando o gargalo de um banco na nuvem é a rede entre computação e armazenamento: envie só o log, deixe o armazenamento materializar páginas e use quórum e LSNs em vez de protocolos de commit de várias fases.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.