Gestione dell'errore principale in una configurazione DB master-slave

how do you persist/maintain availability of data to users if the master goes down?

Se il master scende, gli Slave continuano a girare, senza che alcun nuovo dato arrivi (dal Master inattivo).

Is it implied that there is some arbiter that can elect a new master when the current master goes down?

Una corretta. SqlServer ha "Testimoni", Oracle DataGuard utilizza "Osservatori" e altri DBMS avranno, presumibilmente, qualcosa di simile. La stessa cosa è la stessa: scoprire un Maestro fallito e coordinare il processo di promozione di uno Standby come nuova Primaria.

it appears as if the applications are only being linked to the master

Dipende dall'architettura.

I cluster SqlServer offrono un [singolo] Virtual I.P.Address a cui tutti i client si connettono e il software di clustering risolve dove si trova il Primario e "unisce i punti".

Oracle adotta un approccio diverso, utilizzando la sua tecnologia TNS per informare i clienti su tutti dei nodi disponibili ( primario Standby) e lasciando il software client Oracle per ogni lavoro con quale database il cliente ha bisogno di parlare.

L'immagine a cui si fa riferimento ha una relazione semplificata tra le applicazioni e il DB. Nella mia esperienza con Oracle e la loro soluzione Dataguard (1 master e 1..n 'slaves') posso dire che il 'Master' non è fisso. In qualsiasi momento è possibile modificare (o avere cambiato) il ruolo tra uno "Slave" e il "Master". Per le applicazioni questo è reso trasparente utilizzando una soluzione simile a DNS. Ciò significa che non è un "single point of failure".

Credo che il diagramma sia fuorviante. Come hai identificato correttamente, se l'unica connessione era dall'applicazione al master, una relazione master-slave sarebbe inutile e l'applicazione fallirebbe se il database master fosse andato giù.

Ad esempio, un set di repliche MongoDB è composto da diversi nodi, uno dei quali il primario e gli altri sono secondari. L'applicazione si connette all'intero set di repliche (ad esempio, la stringa di connessione è user:[email protected],host2.local,host3.local ) e legge / scrive sul primario. Se il primario dovesse scendere, i secondari rimanenti terranno un'elezione per determinare un nuovo primario.