La base de datos MYSQL (ibdata1) tiene un tamaño de 73 GB y está configurada para ejecutarse como un servidor de base de datos dedicado en Windows 2008 O / S para tablas INNODB. Estamos ejecutando la copia de seguridad usando mysqldump mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert - set-charset - compress --log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql
El archivo de respaldo Proddb0635.sql se almacena en un servidor separado del servidor de la base de datos. RAM es de 12 GB. El tamaño de la agrupación de almacenamiento intermedio INNODB es de 6 GB. La memoria adicional es de 32 MB. El tamaño de la memoria caché de consultas es de 2 GB. La longitud neta del búfer es de 16 M máx. tamaño de paquete 1 GB.
La versión de mysql es 5.0.67.
Cuando la copia de seguridad no se ejecuta, los usuarios están contentos con el rendimiento.
Cuando se ejecuta la copia de seguridad, la tasa de aciertos de la agrupación de almacenamientos intermedios INNODB es alta, cercana al 100%. No hay lecturas pendientes ni escrituras pendientes. innodb wait free es 0. El uso de la CPU no es alto mín. 9% a máx. 15% La tasa de aciertos de la caché de consultas es baja, aproximadamente 40% con o sin mysqlbackup en ejecución. Actualmente, el Administrador de tareas de Windows muestra que se están utilizando 10 GB de RAM. ¿Debo aumentar Query Cache con solo 2GB de RAM disponible? mysqlld-nt está tomando 9.2 GB de RAM y mysqldump está tomando 5 MB de RAM. Alos, señaló que el tamaño del archivo de volcado es el mismo en presencia o ausencia de la opción --compress.
¿Debo disminuir el tamaño de la agrupación de almacenamiento intermedio iNNODB?
Gracias
Aquí hay algunas ideas que tengo sobre mejorar el rendimiento de mysqldump, dadas sus circunstancias. Aquí está tu comando:
Lo primero que noto es que estás redirigiendo la salida a un sistema de archivos. Dice 'devNas', así que voy a suponer que este es el almacenamiento conectado a la red . Soy fanático de NAS para las copias de seguridad, pero debe estar conectado a una NIC física separada del tráfico de producción . Es posible que no esté saturando el ancho de banda, pero aún así compiten. Esto va a ser más problemático debido a la bandera --quick, ya que vacía cada fila en lugar de mantenerla en la memoria.
Lo siguiente que veo es que has invocado: comprimir. Parece que está ejecutando mysql localmente ya que no usó el modificador -h. Esto puede usar CPU local que es innecesaria en este contexto. ¿Es necesario comprimir? Solo comprime datos entre el cliente mysqldump y el servidor mysql, no el contenido del archivo.
A continuación, veo que está utilizando el indicador --single-transacción. Esto causará CPU extra ya que se está probando en cada selección como parte de mysqldump.
Esto no tiene nada que ver con el rendimiento, pero está utilizando --disable-keys que solo funciona en MyISAM ( manual ).
Es posible que desee experimentar ejecutando mysqldump de forma remota desde un host fuera de línea y moviendo el archivo de volcado al NAS después de la finalización para sacar la mayor cantidad posible de esta operación.
fuente
OBSERVACIÓN # 1
Aquí hay algo a tener en cuenta al realizar un mysqldump contra InnoDB.
Cualquier página sucia que exista en el InnoDB Buffer Pool debe primero ser vaciada al disco. Un mysqldump activará el vaciado de una tabla InnoDB que todavía tiene páginas sucias.
Hay una opción de servidor llamada innodb_max_dirty_pages_pct . El valor predeterminado es 75 es MySQL 5.5 y 90 en versiones de MySQL anteriores a 5.5. En un entorno de producción, está bien dejar este número en el valor predeterminado.
Para ver si tiene muchas páginas sucias en el InnoDB Buffer Pool, ejecute esto:
Por cierto, una página es 16K como se muestra a partir de esto:
Cuando se trata de InnoDB y mysqldump, puede reducir este número en dos circunstancias.
CIRCUNSTANCIA 1: ajústelo permanentemente a 0
Simplemente agregue esto a my.ini:
Esto mantendrá el InnoDB Buffer Pool delgado y medio. El paso de vaciar la tabla InnoDB que se está volcando será rápido porque algunas páginas sucias como sea posible (tal vez 0) necesitarán vaciarse antes de que mysqldump funcione en ella.
El único inconveniente es que si mysqldump desde una base de datos altamente traficada, puede haber un aumento menor en la E / S de escritura debido a que se vacía la página sucia con más frecuencia. Puede determinar si esto es así sin reiniciar mysql ejecutando esto:
Deje la configuración durante 12-24 horas, si el rendimiento de escritura es aceptable, está listo. Si no, configúrelo de nuevo con:
CIRCUNSTANCIA 2: configúrelo en 0 aproximadamente 1 hora antes de mysqldump
Ejecute mysqldump
OBSERVACIÓN # 2
Tienes --complete-insert como una opción mysqldump. Esto incrustará los nombres de columna en cada declaración INSERT antes de la cláusula VALUES. Incluso con --extended-insert, en cada lote de filas que se insertan los nombres de columna se envían al mysqldump. Puede reducir la cantidad de bytes enviados al mysqldump eliminando --complete-insert.
RECOMENDACIÓN
Si tiene otro servidor de Windows que se puede configurar como esclavo, realice los mysqldumps desde ese esclavo en lugar de hacerlo desde la máquina de producción.
fuente