2012-04-07 13 views
5

Con il sharding, come è possibile mantenere una transazione affidabile su più server di database? Ad esempio, se avessi una tabella denominata AccountLedger su un server di database (istanza MySQL) e una tabella denominata User su un altro server di database, è possibile eseguire una transazione su entrambe le istanze di database che saranno entrambe affidabili, oppure rollback in caso di fallimento?Sharding e transazioni con MySQL

transazione

Esempio:

server di database AccountLedger:

START TRANSACTION; 
INSERT INTO AccountLedger SET 
    UserID = @UserID, 
    Date = @Date, 
    Debit = @Debit, 
    Balance = @Balance; 

server di database degli utenti: server di database

START TRANSACTION; 
UPDATE User SET 
    Balance = @Balance 
WHERE UserID = @UserID; 

AccountLedger:

COMMIT; 

utente server di database:

COMMIT; -- What happens if the COMMIT fails here (power goes out or whatever) 

Ho letto un bel po 'su sharding, ma io non riesco a trovare tutte le informazioni sull'uso di operazioni con sharding. Qualcuno può indicarmi la giusta direzione?

risposta

8

E 'possibile farlo con transazioni distribuite. Sono supportati dal motore di archiviazione InnoDB. Troverai più informazioni su di loro e sulla sintassi dei comandi nella documentazione di MySQL: XA Transactions

Sconsiglio di utilizzarli direttamente. Se la coerenza è la maggior parte dei requisiti per l'applicazione ypur, quindi utilizzare un monitor delle transazioni che può prendersene cura. Java EE lo fa per te.

Tuttavia, se la disponibilità è più importante della coerenza, è necessario evitare le transazioni distribuite. Il teorema CAP spiega perché.

0

Disclaimer: io lavoro per ScaleBase (http://www.scalebase.com), un fornitore di una soluzione completa per sharding

Noi di ScaleBase dare la possibilità di utilizzare l'uso di transazioni XA in InnoDB, anche se abbiamo scoperto che possono essere costose prestazioni ... E esattamente nei punti in cui hai bisogno del tuo database per essere il più veloce (inserti massicci, ecc.). Quindi abilitiamo anche "la nostra versione di commit a 2 fasi" che è più veloce e può essere considerata molto vicina a XA in termini di coerenza e potrebbe essere sufficiente per il trade-off ... Questa "nostra versione" include un veloce "sei disponibile" query come SELECT version() a tutti i database partecipanti, e poi commettendoli. Questa è un'aggiunta ad altri meccanismi che abbiamo nel nostro "controllore del traffico del database ScaleBase" sono sufficienti per la maggior parte dei nostri clienti (e quelli che non lo fanno - scelgono ancora di scegliere l'XA completo).

3

È possibile implementare la transazione serializzabile con frammenti incrociati sul lato client se ciascun frammento supporta la linearizzabilità dei tasti e confronta e imposta (il che è vero per MySQL). Questo approccio è utilizzato in Google's Percolator e nello CockroachDB ma nulla impedisce di utilizzarlo con MySQL.

Ho creato un step-by-step visualization di tali transazioni. Spero che ti aiuterà a capirli.

Se stai bene con il livello di isolamento impegnato in lettura, allora ha senso dare un'occhiata a RAMP transactions di Peter Bailis.Possono anche essere implementati nell'ambiente MySQL semplificato.