Tengo un problema grave con el rendimiento de replicación de MySQL 5.5 entre dos máquinas, principalmente tablas myISAM con replicación basada en instrucciones. Los registros binarios y el directorio de datos mysql están ubicados en el mismo Fusion ioDrive.
El problema fue un gran problema recientemente cuando necesitábamos pausar la replicación durante aprox. 3 horas. Le tomó cerca de 10 horas ponerse al día nuevamente sin otra carga.
¿Cómo puedo aumentar el rendimiento de la replicación? La máquina B está básicamente inactiva (poco, IO, 2 núcleos maximizados de 16, mucha RAM libre), ya que solo 1 hilo mySQL estaba escribiendo datos. Aquí hay algunas ideas que tuve:
- Cambie a la replicación basada en filas. En las pruebas, esto solo produjo un aumento del rendimiento del 10-20%
- Actualice a mySQL 5.6 con replicación multiproceso Podríamos dividir fácilmente nuestros datos en bases de datos separadas, y los puntos de referencia parecen indicar que esto ayudaría, pero el código no parece estar listo para la producción.
- Algunas variables de configuración que ayudarán a acelerar la replicación
El problema principal es que si tarda 10 h en ponerse al día después de una pausa de 3 h, esto significa que la replicación está escribiendo 13 h de datos en 10 h, o puede escribir al 130% de la velocidad de entrada de datos. Estoy buscando al menos doble escritura en la máquina maestra en el futuro cercano, por lo que necesita desesperadamente una forma de mejorar el rendimiento de la replicación.
Máquina A:
- Maestro
- 24 GB de RAM
- 1.2TB Fusion ioDrive2
- 2x E5620
- Interconexión Gigabit
my.cnf:
[mysqld]
server-id=71
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp
log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306
log-bin=/data_fio/mysqlbinlog/mysql-bin.log
binlog-format=STATEMENT
replicate-ignore-db=mysql
log-slave-updates = true
# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000
# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32
user=mysql
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
Máquina B:
- Esclavo
- 36 GB de RAM
- 1.2TB Fusion ioDrive2
- 2x E5620
- Interconexión Gigabit
my.cnf:
[mysqld]
server-id=72
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp
log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306
# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000
# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32
user=mysql
symbolic-links=0
plugin-load=archive=ha_archive.so;blackhole=ha_blackhole.so
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
fuente
Respuestas:
Wow, tienes un hardware terriblemente robusto para este problema. No hay mucho más que pueda ofrecerle en cuanto a hardware, con la excepción de actualizar a quizás CPUs Sandy / Ivy Bridge para un 20-50% de mejor rendimiento de las búsquedas de Btree, etc.
Tenga en cuenta que mi fuerte es Innodb, así que voy a
Innodb puede ayudar a aprovechar al máximo toda esa memoria almacenando estas filas de acceso frecuente en su grupo de búferes. Puede ajustarlo para que sea tan grande como desee (digamos el 80% de la memoria) y las nuevas lecturas / escrituras permanecen en la memoria hasta que necesite empujarlas al disco para dejar más espacio para los últimos datos accedidos. En la memoria es un orden de magnitud más rápido que sus FusionIOs.
Hay muchas más características de Innodb, como hashes adaptativos, mecanismos de bloqueo automático, etc. que pueden ser de gran ayuda para su entorno. Sin embargo, usted conoce sus datos mejor que yo.
En el mundo innodb, una buena solución a corto plazo es optimizar su esclavo: ¿realmente necesita todos los índices de su esclavo que tenga en su maestro? Los índices son una bola y una cadena en inserciones / actualizaciones / eliminaciones, INCLUSO con tarjetas Fusion IO. Los IOPS no lo son todo aquí. Sandy / Ivy Bridge Procs tienen mucho mejor rendimiento de memoria y rendimiento informático: pueden marcar una gran diferencia en los Westmeres que tiene ahora. (Figura 20-50% en general). ¡Elimine todos los índices que no necesita en el esclavo!
En segundo lugar, y casi con certeza solo se aplica a innodb, es que mk-prefetch puede saber qué actualizaciones y antes de que el esclavo las escriba. Esto permite que mk-prefetch ejecute primero una consulta de lectura, forzando así que los datos estén en la memoria para cuando la única respuesta ejecute la consulta de escritura. Esto significa que los datos están en la memoria y no en fusionIO, un aumento rápido en el rendimiento del orden de magnitud. Esto hace una GRAN diferencia, más de lo que cabría esperar. Muchas empresas usan esto como una solución permanente. Obtenga más información visitando el Kit de herramientas de Percona .
Tercero, y lo más importante, una vez que hayas actualizado a Innodb, definitivamente revisa Tokutek. Estos muchachos tienen algunas cosas terriblemente increíbles que superan el rendimiento de escritura / actualización / eliminación de Innodb por mucho. Ellos promocionan la velocidad de replicación mejorada como uno de los beneficios clave, y puede ver en sus puntos de referencia por qué Fusions crazy IOPS aún no lo ayudará en el caso de Btrees . (Nota: no verificado de forma independiente por mí). Usan un reemplazo directo de un índice btree que, si bien es horriblemente más complejo, mejora muchas de las limitaciones de velocidad algorítmica de los índices btree.
Estoy en el proceso de considerar la adopción de Tokutek. Si liberan tanta velocidad de escritura, eso me permite agregar más índices. Dado que comprimen los datos y los índices en proporciones tan maravillosas (25x que citan), ni siquiera paga un precio (rendimiento, mantenimiento) por el aumento de datos. Sin embargo, usted paga ($) por su motor, $ 2500 / año por GB precomprimido, IIRC. Tienen descuentos si tiene los datos replicados, pero incluso puede instalar Tokutek en su esclavo y mantener su maestro tal como está. Echa un vistazo a los detalles técnicos en la conferencia MIT Algoritms Open Courseware . Alternativamente, tienen toneladas de material técnico en su blog y libros blancos regulares para aquellos que no tienen 1:20 para ver el video. Creo que este video también ofrece la fórmula Big-O de lo rápido que son las lecturas. Yo tengoasumir que las lecturas son más lentas (¡siempre hay una compensación!), pero la fórmula es demasiado compleja para que yo pueda calcular cuánto. Afirman que es más o menos lo mismo, pero prefiero entender las matemáticas (¡no es probable!). Puede estar en una mejor situación para descubrir esto que yo.
PD: No estoy afiliado a Tokutek, nunca he ejecutado su producto y ni siquiera saben que los estoy mirando.
Actualización :
Veo que tienes algunas otras preguntas en esta página y pensé que debería incluir:
Primero, la búsqueda previa de esclavos seguramente no funcionará para myisam a menos que tenga un entorno excepcional. Esto se debe principalmente a que la captación previa bloqueará las tablas en las que desea escribir, o el subproceso esclavo tiene la tabla bloqueada que necesita el demonio de captación previa. Si sus tablas están extremadamente bien equilibradas para la replicación y se escriben diferentes tablas de forma circular, esto puede funcionar, pero tenga en cuenta que esto es muy teórico. El libro "High Performance Mysql" tiene más información en la sección "Problemas de replicación".
En segundo lugar, presumiblemente su esclavo tiene una carga de 1.0-1.5, puede ser mayor si tiene otros procesos o consultas ejecutándose pero una línea de base de 1.0. Esto significa que es probable que esté vinculado a la CPU, lo cual es probable con su FusionIO a bordo. Como mencioné anteriormente, Sandy / Ivy Bridge va a dar un poco más de empuje, pero probablemente no lo suficiente para atravesar los tiempos más difíciles con un retraso mínimo. Si la carga en este esclavo es principalmente de solo escritura (es decir, no hay muchas lecturas), su CPU seguramente gastará su tiempo calculando posiciones para las inserciones / eliminaciones de btree. Esto debería reforzar mi punto anterior sobre la eliminación de índices no críticos: siempre puede volver a agregarlos más tarde. Desactivar hyperthreading no funcionará, más CPU no es tu enemigo. Una vez que supere los 32 GB de ram, digamos 64 GB, debe preocuparse por la distribución de ram, pero incluso entonces los síntomas son diferentes.
Finalmente, y lo más importante (no omita esta parte;)), supongo que ahora está ejecutando RBR (replicación basada en filas) porque mencionó un aumento de rendimiento no trivial al cambiarlo también. Sin embargo, puede haber una forma de obtener aún más rendimiento aquí. El error Mysql 53375 puede manifestarse si tiene tablas que se replican sin clave primaria. Básicamente, el esclavo no es lo suficientemente inteligente como para usar cualquier cosa que no sea una clave primaria, por lo que la ausencia de una fuerza obliga al hilo de replicación a hacer un escaneo completo de la tabla para cada actualización. Una solución es simplemente agregar una clave primaria benigna y sustituta de autoincremento. Solo haría esto si la tabla fuera grande (por ejemplo, varias decenas de miles de filas o más). Esto, por supuesto, tiene el costo de tener otro índice sobre la mesa, lo que eleva el precio que paga en la CPU. Tenga en cuenta que hay muy pocos argumentos teóricos en contra de esto, ya que InnoDB agrega uno detrás de escena si no lo hace. El único fantasma, sin embargo, no es una defensa útil contra 53375. tungsteno puede superar este problema también, pero que necesita para estar seguro cuando se usa tungsteno que tiene su codificación recta. La última vez que jugué con él, moriría horriblemente cuando cualquier cadena que no sea UTF8 necesitara replicarse. Ese es el momento en que me di por vencido.
fuente
no es una respuesta, pero podría considerar el replicador de tungsteno y sus productos comerciales para una mayor flexibilidad. ¿Es el uso del 100% de la CPU en un solo núcleo el cuello de botella?
fuente
Entonces, si está haciendo copias de seguridad en el esclavo ... y usa tablas de myiasm ... está bloqueando las tablas para hacer las copias de seguridad para evitar daños. Entonces, la replicación no puede funcionar hasta que la copia de seguridad esté completa ... luego se pone al día.
fuente