Sharding y Transacciones con MySQL

transactions

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 en ambas instancias de bases de datos que se confirmarán confiadamente o se retrotraerán en caso de falla?

Transacción de ejemplo:

Servidor de base de datos de 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;

Servidor de base de datos de AccountLedger:

COMMIT;

Servidor de base de datos de usuario:

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

He leído mucho sobre sharding, pero parece que no puedo encontrar ninguna información sobre el uso de 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 consistencia, debe evitar las transacciones distribuidas. El teorema de CAP explica por qué.

Answer 2

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

En ScaleBase, tenemos la opción de utilizar el uso de XA Transactions en InnoDB, aunque descubrimos que puede ser costoso 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 compromiso de 2 fases", que es más rápida y se puede considerar muy cercana a XA en términos de consistencia, y puede ser suficiente para el intercambio ... Esta "nuestra versión" incluye un 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 shard es compatible con la linealizabilidad de clave y comparar y establecer (que es cierto para MySQL). Este enfoque se usa en el Percolator de Google y en el CockroachDB pero nada le impide usarlo con MySQL.

Creé una visualización paso a paso de tales transacciones. Espero que te ayude a entenderlos.

Si está bien con el nivel de aislamiento de lectura confirmada, tiene sentido echar un vistazo a las transacciones de RAMP por Peter Bailis. También se pueden implementar en el entorno MySQL fragmentado.