Quindi la replica master-slave è ottima, ma lascia il master come un singolo punto di errore. Qual è la strategia per risolvere questo problema, se ce n'è uno?
Sto cercando la teoria informatica dietro, non per un prodotto che magicamente supporta.
Ok, lo schiavo potrebbe diventare il nuovo maestro, ma qual è la teoria dietro questa transizione di fail-over? Come è fatto?
Non appena un master fallisce, gli schiavi restanti possono eleggere un nuovo master.
Ad esempio, la documentazione di MongoDB spiega come viene eletto un nuovo master. A seconda dei requisiti specifici, è possibile aggiungere ulteriore complessità, ad esempio la presenza di membri senza diritto di voto.
Se il master originale viene ripristinato, ci sono due alternative:
O diventa un nuovo master e il master corrente diventa uno slave,
Oppure la macchina diventa uno schiavo e avrebbe la possibilità di diventare un maestro solo attraverso una nuova elezione, una volta che il master attuale fallisce.
Per i sistemi non critici, c'è un'altra possibilità. Se un master fallisce, nessuno degli slave può sostituire il master, ma continua a servire richieste di sola lettura, in attesa che il master venga ripristinato. Questo potrebbe essere usato con successo in un contesto in cui il downtime del master è accettabile. Ad esempio, se un'app memorizza i tuoi film preferiti, la parte di scrittura può eventualmente ridursi per alcuni minuti una volta al mese, non appena puoi ancora accedere ai tuoi dati in modalità di sola lettura, il tempo di inattività della parte in cui cambi la tua i dati sono accettabili.
Leggi altre domande sui tag database data-replication