La replica mySQL ha una coerenza immediata dei dati?

Question

Sto considerando una soluzione noSQL per un progetto corrente, ma sono titubante riguardo alla clausola di "coerenza finale" in molti di questi database. La coerenza finale è diversa da quella di un database mySQL in cui la replica è in ritardo? Una soluzione che ho usato in passato con la replica ritardata è quella di leggere dal master quando è necessaria una coerenza immediata dei dati.

Tuttavia, sono confuso sul motivo per cui il database relazionale afferma di avere una consistente coerenza dei dati. Credo che dovrei usare le transazioni e questo mi darà una forte coerenza. È una buona pratica quindi scrivere applicazioni assumendo che la replica di mySQL possa essere ritardata?

Answer 1

La coerenza nel senso utilizzato in ACID indica che tutti i vincoli sono soddisfatti prima e dopo qualsiasi modifica. Quando un sistema assicura che non puoi leggere dati incoerenti, stanno dicendo ad esempio che non leggerete mai i dati in cui una riga figlio fa riferimento a una riga padre inesistente o dove è stata applicata la metà di una transazione, ma la l'altra metà non è stata ancora applicata (l'esempio da manuale è l'addebito su un conto bancario ma non ancora accreditato sul conto bancario del destinatario).

La replica in MySQL è asincrona per impostazione predefinita o "semi-sincrona" nella migliore delle ipotesi. Certamente in entrambi i casi è in ritardo. In effetti, lo slave di replica è sempre in ritardo di almeno una frazione di secondo, perché il master non scrive le modifiche nel suo log binario finché non si impegna la transazione, quindi lo slave deve scaricare il log binario e inoltrare l'evento.

Ma i cambiamenti sono ancora atomici. Non è possibile leggere dati parzialmente modificati. È possibile leggere le modifiche apportate, nel qual caso tutti i vincoli sono soddisfatti oppure le modifiche non sono state ancora eseguite, nel qual caso viene visualizzato lo stato dei dati prima dell'avvio della transazione.

così si potrebbe leggere temporaneamente vecchi dati in un sistema di replica che in ritardo, ma non sarà possibile leggere incoerenti dati.

Considerando che in un sistema "alla fine coerente", è possibile leggere i dati che sono parzialmente aggiornati, in cui l'account è stato addebitato ma il secondo account non è ancora stato accreditato. Pertanto, può vedere dati incoerenti.

Hai ragione che potrebbe essere necessario fare attenzione a leggere dagli slave di replica se l'applicazione richiede dati assolutamente attuali. Ogni applicazione ha una tolleranza diversa per il ritardo dello slave e, in effetti, all'interno di un'applicazione, le diverse query hanno una tolleranza diversa per il ritardo. Ho fatto una presentazione al riguardo: http://www.slideshare.net/billkarwin/read-write-split