Sharding y transacciones con MySQL

Question

Con la fragmentación, ¿cómo puede mantener una transacción confiable en múltiples servidores de bases de datos?

Por ejemplo, si tuviera una tabla llamada AccountLedger en un servidor de base de datos (instancia de MySQL) y una tabla llamada User en otro servidor de base de datos, es posible ejecutar una transacción a través de ambas instancias de base que a la vez se comprometan de forma fiable, o revertir en caso de falla?

Ejemplo transacción:

servidor de base de datos AccountLedger:

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

servidor de base de datos de usuario:

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

AccountLedger servidor de base de datos:

COMMIT; 

Usuario servidor de base de datos:

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

He leído mucho sobre sharding, pero me parece que no puede encontrar ninguna información sobre el uso de las transacciones con sharding. ¿Alguien me puede apuntar en la dirección correcta?

Answer 1

Es posible hacer esto con transacciones distribuidas. Son compatibles con el motor de almacenamiento InnoDB. Encontrará más información sobre ellos y sobre la sintaxis de los comandos en la documentación de MySQL: XA Transactions

Aconsejo no usarlos directamente. Si la consistencia es la mayoría de los requisitos para la aplicación ypur, entonces use un monitor de transacciones que pueda encargarse de ello. Java EE hace eso por ti.

Sin embargo, si la disponibilidad es más importante que la coherencia, debe evitar las transacciones distribuidas. El teorema de CAP explica por qué.

Answer 2

responsabilidad: yo trabajo para ScaleBase (http://www.scalebase.com), un proveedor de una solución completa para sharding

Nosotros en ScaleBase dará la opción de utilizar el uso de transacciones XA en InnoDB, aunque descubrimos que pueden ser costosos para el rendimiento ... Y exactamente en los lugares que necesita que su base de datos sea la más rápida (inserciones masivas, etc.). Por lo tanto, también habilitamos "nuestra versión de confirmación de 2 fases", que es más rápida y se puede considerar muy cercana a XA en términos de coherencia, y puede ser suficiente para el intercambio ... Esta "nuestra versión" incluye una rápida consulta "¿estás disponible?" como SELECT version() a todas las bases de datos participantes, y luego enviándolas. Esto es una adición a otros mecanismos que tenemos en nuestro "controlador de tráfico de la base de datos ScaleBase" que son suficientes para la mayoría de nuestros clientes (y para aquellos que no lo hacen, aún pueden elegir XA completo).

Answer 3

Puede implementar la transacción serializable de cross shard en el lado del cliente si cada fragmento admite linealización de la clave y comparar y establecer (que es cierto para MySQL). Este enfoque se usa en Google's Percolator y en CockroachDB, pero nada le impide usarlo con MySQL.

He creado un step-by-step visualization de tales transacciones. Espero que te ayude a entenderlos.

Si está de acuerdo con el nivel de aislamiento de lectura confirmada, entonces tiene sentido echarle un vistazo al RAMP transactions de Peter Bailis.También se pueden implementar en el entorno MySQL fragmentado.