No se puede balancear una escritura.
Nodos de base de datos idénticos parecen capacidad de escritura multiplicada. Reparta sus escrituras entre ellos y el clúster fabrica deadlocks. El diseño que funciona.
En este artículo 2 secciones
- La configuración intuitiva de un clúster: nodos idénticos, un balanceador de carga, todo en round-robin. Parece capacidad multiplicada.
- Bajo una carga completamente normal entrega errores de deadlock a los editores a mitad de publicación, sin ningún bug de bloqueo en el código. Dos editores, dos nodos, una fila caliente, y la comprobación de conflictos del clúster rechaza a uno de ellos.
- La solución contraintuitiva: cada escritura va a un único nodo elegido, y solo las lecturas se reparten.
- El giro que responde a «pero ¿no es más rápido distribuir?»: el volumen de escritura rara vez es la limitación. La capacidad de lectura es lo que escala, y los errores desaparecen.
Ha comprado un clúster de base de datos. Nadie compra varias unidades de algo para usar una, así que la configuración del balanceador prácticamente se escribe sola: round-robin de todo entre todos los nodos. La creencia que hay debajo es simple: una sola consulta no irá más rápido, pero muchas sí, repartidas entre las máquinas. Suena obviamente correcto. También es la forma más habitual en que vemos mal usado este tipo de clúster.
El bug que no está en el código
Bajo una carga ordinaria, los editores pulsan guardar de forma intermitente y reciben de vuelta un error de base de datos en bruto a través del CMS: deadlock found. Es intermitente y difícil de reproducir, y ninguna lectura del código de la aplicación lo encontrará, porque el bug no está en el código.
La carga que se convierte en el arma es una carga ordinaria. Un CMS reescribe un puñado de filas de configuración con nombre global en casi cada acción. Un plugin de SEO reconstruye su sitemap en cada guardado. Las marcas de tiempo de inicio de sesión y los contadores de visitas tocan todos las mismas filas calientes. El round-robin dispersa esas escrituras en competencia entre todos los nodos. Cada nodo acepta su propia escritura localmente, y después el paso de certificación del clúster detecta la colisión en el momento del commit y se la devuelve a un cliente que no hizo nada mal. Dos editores, dos nodos, la misma fila: error 1213.
Un deadlock bajo carga normal, en un clúster, sin ningún patrón de bloqueo en la aplicación, es un síntoma de enrutamiento. La carga no está mal. La topología sí.
Un único escritor por seguridad, reparta las lecturas
¿Canalizar todas las escrituras a un nodo desperdicia los demás? No. Las lecturas se equilibran uniformemente por todo el clúster y cada escritura va al único escritor elegido. El instinto del round-robin acierta con las lecturas y se equivoca con las escrituras; el enrutamiento con un único escritor conserva la mitad que acierta y elimina los errores que genera la otra mitad. Si su primer instinto en un clúster ocupado es escalar hacia arriba, la lección hermana es que el movimiento correcto suele ser el contrario (dimensione hacia abajo, no hacia arriba).
1213
1
“Un clúster es multi-primary-capable y single-writer-safe. Son frases distintas.”
Si opera un clúster con lecturas balanceadas, vaya a averiguar dónde aterrizan realmente sus escrituras. Si la respuesta es «donde el balanceador las mande», está a una tarde ocupada de fabricar deadlocks a partir de su propio éxito. La comprobación cuesta leer una configuración. La solución es una regla de enrutamiento, no una reescritura.
Respuestas directas
¿Por qué recibo errores de deadlock (1213) en mi clúster Galera o PXC bajo carga normal?+
Si no hay ningún bug de bloqueo en su código, revise el enrutamiento de escrituras. Las escrituras dispersas entre nodos colisionan sobre filas calientes en el momento de la certificación, y el clúster informa de la colisión como un deadlock a un cliente inocente. Enrute cada escritura a un solo nodo y toda esa clase de error desaparece.
¿Enviar todas las escrituras a un nodo no desperdicia mi clúster?+
Las escrituras casi nunca son el cuello de botella; las lecturas son el volumen. Con enrutamiento de un único escritor, las lecturas siguen equilibrándose entre todos los nodos y el rendimiento de escritura no cambia, porque en la práctica un nodo siempre estaba haciendo todo el trabajo de escritura.
¿Puede un clúster Galera hacer escrituras multi-master?+
Es capaz de aceptar escrituras en todos los nodos, y es seguro cuando no tiene que certificar escrituras en competencia sobre filas calientes procedentes de varios de ellos a la vez. Multi-primary-capable, single-writer-safe. Use la capacidad para el failover, no para distribuir carga.
¿Cómo escalo entonces las escrituras de base de datos?+
Primero demuestre que lo necesita: mida el volumen de escritura frente al margen del único escritor, que suele ser un error de redondeo al lado de las lecturas. El escalado real de escrituras es territorio de sharding o de rediseño de la carga, no un ajuste del balanceador.
¿Qué enruta lecturas y escrituras de forma distinta?+
Una capa de proxy que hable el protocolo de la base de datos puede separarlas: las lecturas se reparten, las escrituras se fijan al escritor elegido, y el failover reelige un escritor automáticamente. Operamos este patrón en producción: ProxySQL delante de Percona XtraDB Cluster.
¿Ve deadlocks que no encuentra en su código?
Envíenos solo el error y cómo está balanceado su clúster. Si es la topología, se lo mostraremos, y lo arreglaremos en el enrutamiento, no en su aplicación.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero