Arquitetura de banco de dados: troca de papéis
O curso examina a troca automática de papéis no Rails, a configuração database_selector que manda cada requisição para o primário ou para uma réplica. Ele apresenta as três peças do middleware: um contexto que lembra, um resolvedor que decide e a ligação entre os dois. As lições explicam por que o verbo HTTP define o que é leitura e como a sessão guarda um timestamp da última escrita. Mostram por que o prevent_writes faz um GET que escreve falhar toda vez. Tratam ainda da escolha do delay pelo atraso medido e da troca da política padrão.
O que você vai aprender
- ✓Como o middleware database_selector divide o trabalho entre contexto, resolvedor e a ligação entre eles
- ✓Por que GET e HEAD contam como leitura e como achar requisições GET que escrevem
- ✓Como o timestamp da sessão protege a leitura das próprias escritas e onde essa proteção acaba
- ✓Por que prevent_writes: true nos dois caminhos de leitura faz um GET que escreve falhar toda vez
- ✓Como escolher o delay pelo atraso máximo de replicação na hora mais movimentada
- ✓Quando trocar o resolvedor ou o contexto, ou usar blocos connected_to explícitos
Uma linha de configuração
A troca automática de papéis é ligada por uma única linha, e o tamanho dessa linha engana: ela muda com qual banco cada requisição da aplicação conversa.
Ler a aula completa grátis →Currículo
7 aulasUma linha de configuração
Uma linha de configuração instala um middleware com contexto, resolvedor e ligação que roteiam cada requisição.
O verbo é o sinal
O resolvedor trata GET e HEAD como leituras, então é preciso auditar antes as requisições GET que escrevem.
A sessão lembra
A sessão guarda um timestamp da última escrita, que protege as próprias escritas e deixa as alheias sem proteção.
prevent_writes é a parte que passa batido
Os dois caminhos de leitura definem prevent_writes, então um GET que escreve falha sempre, mesmo sem réplica.
Escolhendo o delay
O delay afirma que o atraso de replicação nunca passa dele, então escolha pelo atraso máximo medido.
Substituindo a política
Resolvedores próprios, contextos próprios ou blocos connected_to explícitos podem substituir a política padrão de verbo e sessão.
Juntando tudo
Uma revisão da política inteira e um desafio para implementar a decisão resolve, incluindo o prevent_writes.