Percona XtraBackup

Percona XtraBackup es un software de línea de comandos de código abierto, portátil, gratuito y sin bloqueo que actúa como una solución de respaldo independiente para los bien conocidos motores de almacenamiento XtraDB e InnoDB. Cuenta con verificación automática de respaldo y ofrece tiempos de actividad más altos que otros productos similares.

El programa es totalmente compatible con los servidores de bases de datos MySQL y MariaDB, y es muy utilizado por el popular servicio de redes sociales de Facebook para copias de seguridad incrementales. Está diseñado para resolver problemas del mundo real al realizar copias de seguridad de bases de datos muy grandes y muy cargadas.

Las características clave incluyen la capacidad de realizar copias de seguridad en línea mientras evita interrumpir su base de datos, la capacidad de realizar copias de seguridad de secuencias a otro servidor, así como la capacidad de realizar copias de seguridad incrementales mientras ahorra dinero en espacio de disco y ancho de banda de red.

Con Percona XtraBackup, sus copias de seguridad se completarán de manera confiable y rápida. También puede crear nuevos esclavos de replicación fácilmente, realizar análisis avanzados de datos e índices, y mover tablas individuales entre servidores sin reiniciar, una tarea que requiere XtraDB para su importación.

El software admite varios sabores de MySQL, entre los que podemos mencionar MySQL, MariaDB, MariaDB Galera Cluster, Percona Server y Percona XtraDB Cluster. También es compatible con todos los sistemas operativos GNU / Linux, que funcionan bien en hardware de 32 y 64 bits.

Entre otras características, podemos mencionar el bloqueo de copias de seguridad MyISAM, copias de seguridad comprimidas completas, copias de seguridad incrementales, copias de seguridad incrementales rápidas, copias de seguridad incrementales con registros archivados y registro REDO solamente, copias de seguridad locales paralelas, copia de respaldo, registro de aplicaciones, compresión y encriptación.

Además, viene con soporte rsync para sincronización de archivos de última generación, exportación de tablas individuales, manejo mejorado de FTWRL, copias de seguridad compactas, soporte de recuperación puntual, copias de seguridad fuera de línea, así como soporte para la nube copias de seguridad.

Percona XtraBackup está escrito en los lenguajes de programación C, C ++ y Perl. Es un software de línea de comandos, distribuido como paquetes binarios preconstruidos para distribuciones de Ubuntu, Debian y Red Hat Enterprise Linux, así como archivos binarios universales y fuentes.

Qué es nuevo en este lanzamiento:

• Percona XtraBackup segfault durante la fase de preparación de ciertas páginas FTS. Error solucionado # 1460138.
• Se corrigió el error de compilación debido a la falta de dependencia causada por el error de flujo ascendente # 77226. Error solucionado # 1461129.
• La regresión introducida al arreglar un error # 1403237 en Percona XtraBackup 2.2.8 podría causar que xtrabackup lea un registro de rehacer desde un desplazamiento incorrecto que podría causar una aserción. Error corregido # 1464608.
• Se corrigió la variable local-thread sin inicializar current_thd. Esto también corrige completamente el error # 1415191. Error corregido # 1467574.
• Después del lanzamiento de Percona XtraBackup 2.2.11, innobackupex emite una TABLA DE LAVADO antes de ejecutar las TABLAS DE LIMPIEZA CON LEER BLOQUEO. Si bien ayudará a las copias de seguridad en alguna situación, también implica que FLUSH TABLE se escribirá en el registro binario. En MariaDB 10.0 con GTID activado, cuando se realizó una copia de seguridad en el esclavo, esto alteró el GTID de ese esclavo y Percona XtraBackup ya no veía el GTID correcto. Error solucionado # 1466446 (Julien Pivotto).
• La compilación de RPM de Percona XtraBackup aún requería bzr. Error solucionado # 1466888 (Julien Pivotto).
• La compilación de los RPM Percona XtraBackup con la opción XB_VERSION_EXTRA crearía una versión de RPM incorrecta. Error solucionado # 1467424 (Julien Pivotto).
• Percona XtraBackup se completaría correctamente incluso cuando el registro de rehacer no se haya copiado por completo. Esto significa que las copias de seguridad se consideraron exitosas incluso cuando estaban corruptas. Error corregido # 1470847.
• En casos raros cuando hay dos o más espacios de tabla con el mismo ID en el directorio de datos, xtrabackup toma el primero por orden léxico, lo que podría llevar a perder la tabla correcta. Error corregido # 1475487.
• Percona XtraBackup faltaba revision_id en binarios. Error solucionado # 1394174.

Qué hay de nuevo en la versión 2.4.8:

• Percona XtraBackup segfault durante la fase de preparación de ciertas páginas FTS. Error solucionado # 1460138.
• Se corrigió el error de compilación debido a la falta de dependencia causada por el error de flujo ascendente # 77226. Error solucionado # 1461129.
• La regresión introducida al arreglar un error # 1403237 en Percona XtraBackup 2.2.8 podría causar que xtrabackup lea un registro de rehacer desde un desplazamiento incorrecto que podría causar una aserción. Error corregido # 1464608.
• Se corrigió la variable local-thread sin inicializar current_thd. Esto también corrige completamente el error # 1415191. Error corregido # 1467574.
• Después del lanzamiento de Percona XtraBackup 2.2.11, innobackupex emite una TABLA DE LAVADO antes de ejecutar las TABLAS DE LIMPIEZA CON LEER BLOQUEO. Si bien ayudará a las copias de seguridad en alguna situación, también implica que FLUSH TABLE se escribirá en el registro binario. En MariaDB 10.0 con GTID activado, cuando se realizó una copia de seguridad en el esclavo, esto alteró el GTID de ese esclavo y Percona XtraBackup ya no veía el GTID correcto. Error solucionado # 1466446 (Julien Pivotto).
• La compilación de RPM de Percona XtraBackup aún requería bzr. Error solucionado # 1466888 (Julien Pivotto).
• La compilación de los RPM Percona XtraBackup con la opción XB_VERSION_EXTRA crearía una versión de RPM incorrecta. Error solucionado # 1467424 (Julien Pivotto).
• Percona XtraBackup se completaría correctamente incluso cuando el registro de rehacer no se haya copiado por completo. Esto significa que las copias de seguridad se consideraron exitosas incluso cuando estaban corruptas. Error corregido # 1470847.
• En casos raros cuando hay dos o más espacios de tabla con el mismo ID en el directorio de datos, xtrabackup toma el primero por orden léxico, lo que podría llevar a perder la tabla correcta. Error corregido # 1475487.
• Percona XtraBackup faltaba revision_id en binarios. Error solucionado # 1394174.

Qué hay de nuevo en la versión 2.4.7:

• Percona XtraBackup segfault durante la fase de preparación de ciertas páginas FTS. Error solucionado # 1460138.
• Se corrigió el error de compilación debido a la falta de dependencia causada por el error de flujo ascendente # 77226. Error solucionado # 1461129.
• La regresión introducida al arreglar un error # 1403237 en Percona XtraBackup 2.2.8 podría causar que xtrabackup lea un registro de rehacer desde un desplazamiento incorrecto que podría causar una aserción. Error corregido # 1464608.
• Se corrigió la variable local-thread sin inicializar current_thd. Esto también corrige completamente el error # 1415191. Error corregido # 1467574.
• Después del lanzamiento de Percona XtraBackup 2.2.11, innobackupex emite una TABLA DE LAVADO antes de ejecutar las TABLAS DE LIMPIEZA CON LEER BLOQUEO. Si bien ayudará a las copias de seguridad en alguna situación, también implica que FLUSH TABLE se escribirá en el registro binario. En MariaDB 10.0 con GTID activado, cuando se realizó una copia de seguridad en el esclavo, esto alteró el GTID de ese esclavo y Percona XtraBackup ya no veía el GTID correcto. Error solucionado # 1466446 (Julien Pivotto).
• La compilación de RPM de Percona XtraBackup aún requería bzr. Error solucionado # 1466888 (Julien Pivotto).
• La compilación de los RPM Percona XtraBackup con la opción XB_VERSION_EXTRA crearía una versión de RPM incorrecta. Error solucionado # 1467424 (Julien Pivotto).
• Percona XtraBackup se completaría correctamente incluso cuando el registro de rehacer no se haya copiado por completo. Esto significa que las copias de seguridad se consideraron exitosas incluso cuando estaban corruptas. Error corregido # 1470847.
• En casos raros cuando hay dos o más espacios de tabla con el mismo ID en el directorio de datos, xtrabackup toma el primero por orden léxico, lo que podría llevar a perder la tabla correcta. Error corregido # 1475487.
• Percona XtraBackup faltaba revision_id en binarios. Error solucionado # 1394174.

Qué hay de nuevo en la versión 2.4.6:

• Percona XtraBackup segfault durante la fase de preparación de ciertas páginas FTS. Error solucionado # 1460138.
• Se corrigió el error de compilación debido a la falta de dependencia causada por el error de flujo ascendente # 77226. Error solucionado # 1461129.
• La regresión introducida al arreglar un error # 1403237 en Percona XtraBackup 2.2.8 podría causar que xtrabackup lea un registro de rehacer desde un desplazamiento incorrecto que podría causar una aserción. Error corregido # 1464608.
• Se corrigió la variable local-thread sin inicializar current_thd. Esto también corrige completamente el error # 1415191. Error corregido # 1467574.
• Después del lanzamiento de Percona XtraBackup 2.2.11, innobackupex emite una TABLA DE LAVADO antes de ejecutar las TABLAS DE LIMPIEZA CON LEER BLOQUEO. Si bien ayudará a las copias de seguridad en alguna situación, también implica que FLUSH TABLE se escribirá en el registro binario. En MariaDB 10.0 con GTID activado, cuando se realizó una copia de seguridad en el esclavo, esto alteró el GTID de ese esclavo y Percona XtraBackup ya no veía el GTID correcto. Error solucionado # 1466446 (Julien Pivotto).
• La compilación de RPM de Percona XtraBackup aún requería bzr. Error solucionado # 1466888 (Julien Pivotto).
• La compilación de los RPM Percona XtraBackup con la opción XB_VERSION_EXTRA crearía una versión de RPM incorrecta. Error solucionado # 1467424 (Julien Pivotto).
• Percona XtraBackup se completaría correctamente incluso cuando el registro de rehacer no se haya copiado por completo. Esto significa que las copias de seguridad se consideraron exitosas incluso cuando estaban corruptas. Error corregido # 1470847.
• En casos raros cuando hay dos o más espacios de tabla con el mismo ID en el directorio de datos, xtrabackup toma el primero por orden léxico, lo que podría llevar a perder la tabla correcta. Error corregido # 1475487.
• Percona XtraBackup faltaba revision_id en binarios. Error solucionado # 1394174.

Qué hay de nuevo en la versión 2.4.3:

• Percona XtraBackup segfault durante la fase de preparación de ciertas páginas FTS. Error solucionado # 1460138.
• Se corrigió el error de compilación debido a la falta de dependencia causada por el error de flujo ascendente # 77226. Error solucionado # 1461129.
• La regresión introducida al arreglar un error # 1403237 en Percona XtraBackup 2.2.8 podría causar que xtrabackup lea un registro de rehacer desde un desplazamiento incorrecto que podría causar una aserción. Error corregido # 1464608.
• Se corrigió la variable local-thread sin inicializar current_thd. Esto también corrige completamente el error # 1415191. Error corregido # 1467574.
• Después del lanzamiento de Percona XtraBackup 2.2.11, innobackupex emite una TABLA DE LAVADO antes de ejecutar las TABLAS DE LIMPIEZA CON LEER BLOQUEO. Si bien ayudará a las copias de seguridad en alguna situación, también implica que FLUSH TABLE se escribirá en el registro binario. En MariaDB 10.0 con GTID activado, cuando se realizó una copia de seguridad en el esclavo, esto alteró el GTID de ese esclavo y Percona XtraBackup ya no veía el GTID correcto. Error solucionado # 1466446 (Julien Pivotto).
• La compilación de RPM de Percona XtraBackup aún requería bzr. Error solucionado # 1466888 (Julien Pivotto).
• La compilación de los RPM Percona XtraBackup con la opción XB_VERSION_EXTRA crearía una versión de RPM incorrecta. Error solucionado # 1467424 (Julien Pivotto).
• Percona XtraBackup se completaría correctamente incluso cuando el registro de rehacer no se haya copiado por completo. Esto significa que las copias de seguridad se consideraron exitosas incluso cuando estaban corruptas. Error corregido # 1470847.
• En casos raros cuando hay dos o más espacios de tabla con el mismo ID en el directorio de datos, xtrabackup toma el primero por orden léxico, lo que podría llevar a perder la tabla correcta. Error corregido # 1475487.
• Percona XtraBackup faltaba revision_id en binarios. Error solucionado # 1394174.

¿Qué hay de nuevo en la versión 2.2.9:

• Percona XtraBackup 2.1.2 se bloqueará al realizar el estado Transferencia de instantáneas Error corregido # 1182698.

¿Qué hay de nuevo en la versión 2.2.8:

• Percona XtraBackup 2.1.2 se bloqueará al realizar el estado Transferencia de instantáneas Error corregido # 1182698.

Qué hay de nuevo en la versión 2.1.2:

• Errores solucionados:
• Utilizando el paquete DBD :: MySQL de Perl para la comunicación del servidor en lugar de generar el cliente de la línea de comandos de MySQL introdujo una regresión que causó la falla de la opción innobackupex -galera-info. Error corregido # 1180672.
• Al formato de xtrabackup_galera_info le faltaba el separador ':' entre los valores de wsrep_local_state_uuid y wsrep_last_committed. Error corregido # 1181222.
• la detección de la versión automática de innobackupex no funcionó correctamente para las versiones más recientes de Percona Server y MySQL 5.1, lo que podría causar la falla de innobackupex. Errores corregidos # 1181092, # 1181099 y # 1180905.
• Al hacer una copia de seguridad de un servidor que no es un esclavo de replicación con la opción innobackupex -slave-info, innobackupex falló con un error fatal. Se reemplazó el error fatal con un mensaje de diagnóstico sobre innobackupex -slave-info siendo ignorado en tal caso. Error corregido # 1180662.
• Los valores bajos para wait_timeout en el servidor pueden hacer que el servidor cierre la conexión mientras se realiza la copia de seguridad. Se corrigió estableciendo el valor más grande para la opción wait_timeout en el servidor para evitar que el servidor cierre las conexiones si el valor global wait_timeout es demasiado bajo. Error corregido # 1180922.
• Otras correcciones de errores: error corregido # 1177182.

Qué hay de nuevo en la versión 2.0.7:

• Nuevas características:
• Esta versión de Percona XtraBackup ha implementado soporte completo para las nuevas características de MySQL 5.6 (GTID, espacios de tablas remotas / transportables, tablespace de deshacer separado, archivos de volcado del grupo de búferes estilo 5.6).
• Percona XtraBackup ha implementado soporte para la carga previa de la agrupación de almacenamiento intermedio de InnoDB introducida en MySQL 5.6. Comenzando con los volcados del grupo de búfer MySQL 5.6 se pueden producir y cargar para un calentamiento más rápido del servidor después del inicio. Esta característica es similar a la descarga / restauración del grupo de búferes en el servidor de Percona. El volcado de agrupación de almacenamiento intermedio de MySQL 5.6 se copia en el directorio de respaldo durante la etapa de respaldo. Durante la etapa de copia de respaldo (restauración), se copia de nuevo al directorio de datos. Después de que se restaure la copia de seguridad, el servidor puede cargar el volcado del grupo de búferes automáticamente al inicio o bajo demanda.
• El intervalo de tiempo entre las comprobaciones realizadas por el hilo de copia de registro ahora se puede configurar mediante el valor de innobackupex -log-copy-interval. Hacer que el intervalo sea configurable permite reducir el tiempo entre revisiones, lo que puede evitar que las fallas de XtraBackup causadas por los registros de registro en el registro transaccional se sobrescriban antes de que sean copiadas por el hilo de copia de registro.
• Percona XtraBackup ahora almacena el valor de GTID en xtrabackup_binlog_info cuando realiza la copia de seguridad de MySQL y Percona Server 5.6 con el modo GTID habilitado. Se puede encontrar un ejemplo de cómo se puede usar esta información para crear / restaurar un esclavo en esta publicación de blog.
• Opción Percona XtraBackup xtrabackup -export ahora admite espacios de tablas transportables introducidos en MySQL 5.6. Esta opción se puede usar para producir archivos de metadatos de estilo 5.6, que ALTER TABLE IMPORT TABLESPACE puede importar en MySQL y Percona Server 5.6 como se describe en la guía Exportar e importar tablas.
• Errores solucionados:
• xtrabackup_56 binary estaba presente en los paquetes rpm y deb, pero faltaba en el paquete fuente .tar.gz. Se corrigió agregando el binario faltante a .tar.gz también. Error corregido # 1158948.
• innobackupex podría fallar al realizar la copia de seguridad 5.6 debido a que se vincula la biblioteca SSL incorrecta. Error corregido # 1168540.
• Percona XtraBackup se bloqueará al preparar la copia de seguridad 5.6 con tablas particionadas. Error corregido # 1169169.
• Las tablas que se descartaron entre tomar una copia de seguridad completa y una incremental estuvieron presentes en el directorio de copia de seguridad completo, y no se eliminaron cuando se fusionaron las copias de seguridad incrementales. Se solucionó al eliminar los archivos correspondientes a las tablas que faltan en el directorio de copia de seguridad incremental. Error corregido # 856400.
• Percona XtraBackup dejaría archivos xtrabackup_tmp * obsoletos en el datadir después de aplicar copias de seguridad incrementales. Error solucionado # 1079135.
• Se corrigieron un par de advertencias encontradas en innobackupex cuando todas las advertencias se hicieron FATAL. Error corregido # 1116177.
• Si hay miles de tablas y IO lenta, entonces XtraBackup puede pasar mucho tiempo abriendo todos los espacios de tablas. Se implementó la optimización y ahora XtraBackup evita cargar espacios de tabla no relevantes cuando se realiza una copia de seguridad parcial, lo que acelera el proceso de copia de seguridad. Error corregido # 1130145.
• Percona XtraBackup no inicializó los datos por subproceso en el subproceso de copia de logs, lo que podría causar el bloqueo de XtraBackup. Error corregido # 1166888.
• La dependencia del paquete ha cambiado de mysql abstracto a archivo real / usr / bin / mysql, porque los paquetes rpm de Oracle ya no satisfacen la dependencia de mysql que es requerida por XtraBackup rpms. Error solucionado # 1095972.
• Percona XtraBackup fallaría al preparar la copia de seguridad de MySQL 5.6 si los archivos de registro eran más grandes que 4G en el servidor de origen. Error corregido # 1164979.
• Debido a la diferente implementación en MySQL 5.6, los mensajes de error no se imprimieron en stderr directamente. Debido a eso, xtrabackup_56 nunca imprime todos los mensajes de error o diagnóstico de InnoDB. Error corregido # 1169971.
• innobackupex seguiría ejecutándose con FLUSH TABLES WITH READ LOCK, incluso si xtrabackup fallara al copiar registros. Se corrigió al finalizar el proceso de xtrabackup inmediatamente en la falla de copia de registro. Error corregido # 1170806.
• inobackupex fallaría si el SQL_MODE se estableció en ANSI_QUOTES. Error corregido # 945161.
• La falta de space_id de * .ibd.meta llevaría a la aserción. Se corrigió reemplazando la aserción con el mensaje de error. Error corregido # 1112224.
• Se corrigió el error tipográfico en el resultado de error de innobackupex. Error corregido # 1157225.
• Cuando se construía desde el origen, innodb56 no tenía una opción para inhabilitar DTrace, como lo hizo innodb55. Se corrigió añadiendo -DENABLE_DTRACE = opción de compilación OFF para innodb56 también. Error corregido # 1169509.
• innobackupex no manejaba la opción innodb_data_file_path, lo que podría hacer que la copia de seguridad fallara. Error corregido # 1169726.
• Para los binarios de Debian y Linux, el mensaje de versión que debería incluir la revisión mostraba & quot; indefinido & quot ;. Error corregido # 1171721.
• El código redundante se ha eliminado de xtrabackup.cc. Error corregido # 1162765.
• Otras correcciones de errores: error corregido # 1158154, error corregido # 1170340, error corregido # 1088309, error corregido # 1088307.

Qué hay de nuevo en la versión 2.0.6:

• Nuevas características:
• XtraBackup ha implementado soporte básico para MySQL 5.6, Percona Server 5.6 y MariaDB 10.0. El soporte básico significa que estas versiones son reconocidas por XtraBackup, y que la copia de seguridad / restauración funciona siempre que no se utilicen características específicas de 5.6 (como GTID, espacios de tablas remotas / transportables, tablespace de deshacer separado, archivos de volcado del grupo de búferes de estilo 5.6) .
• Errores solucionados:
• Los espacios de tabla InnoDB individuales con un tamaño inferior a 1 MB se ampliaron a 1 MB en la operación de preparación de copia de seguridad. Esto condujo a un gran aumento en el uso del disco en los casos en que hay muchos espacios de tabla InnoDB pequeños. Error solucionado # 950334 (Daniel Frett, Alexey Kopytov).
• Se corrigió el problema que causaba que las bases de datos correspondientes a los subdirectorios de datos inaccesibles fueran ignoradas por XtraBackup sin advertencia o mensajes de error. Esto sucedía porque el código InnoDB ignoraba silenciosamente los subdirectorios de datos que no podía abrir. Error solucionado # 664986 (Alexey Kopytov).
• En algunas circunstancias, XtraBackup podría no copiar un espacio de tabla con un valor de opción alto - paralelo y un valor bajo de innodb_open_files. Error solucionado # 870119 (Alexey Kopytov).
• La corrección para el error # 711166 introdujo una regresión que causó que las copias de seguridad de particiones individuales fallaran cuando se usaban con la opción --include en innobackupex o la opción --tables en xtrabackup. Error corregido # 1130627 (Alexey Kopytov).
• innobackupex no agregó la configuración de archivo por tabla para las copias de seguridad independientes de la tabla. Se corrigió haciendo que XtraBackup habilitara automáticamente innodb_file_per_table cuando se usa la opción --export. Error solucionado # 930062 (Alexey Kopytov).
• En algunas circunstancias, XtraBackup podría fallar en una preparación de copia de seguridad con innodb_flush_method = O_DIRECT. Error solucionado # 1055547 (Alexey Kopytov).
• innobackupex no pasó la opción --tmpdir al binario xtrabackup, por lo que el tmpdir del servidor siempre se usa para archivos temporales. Error solucionado # 1085099 (Alexey Kopytov).
• XtraBackup ha mejorado el informe de errores para versiones de servidor no reconocidas. Error solucionado # 1087219 (Alexey Kopytov).
• Se corrigió la falta de dependencia de rpm para el paquete Perl Time :: HiRes que hacía que innobackupex fallara en las instalaciones mínimas de CentOS. Error solucionado # 1121573 (Alexey Bychko).
• inobackupex fallaría cuando --no-lock y --rsync se usaran conjuntamente. Error solucionado # 1123335 (Sergei Glushchenko).
• La corrección para el error # 1055989 introdujo una regresión que provocó que el archivo xtrabackup_pid permanezca en el directorio temporal después de la ejecución. Error solucionado # 1114955 (Alexey Kopytov).
• Los mensajes de depuración innecesarios se han eliminado del resultado de XtraBackup. Error corregido # 1131084 (Alexey Kopytov).
• Otras correcciones de errores: error corregido # 1153334 (Alexey Kopytov), ​​error corregido # 1098498 (Laurynas Biveinis), error corregido # 1132763 (Laurynas Biveinis), error corregido # 1142229 (Laurynas Biveinis), error corregido # 1130581 (Laurynas Biveinis ).

Qué hay de nuevo en la versión 2.0.5:

• Nuevas características:
• Nueva opción --defaults-extra-file ha sido introducida. Esta opción especifica a partir de qué archivo adicional leer las opciones predeterminadas de MySQL antes del archivo predeterminado estándar. Se puede usar para cargar la combinación de usuario / contraseña para el usuario de respaldo dedicado desde un archivo de configuración separado, para evitar almacenarlo en el crontab o en un script en algún lugar del sistema.
• Errores solucionados:
• En el caso de las copias de seguridad de transmisión, innobackupex reanudaría el proceso XtraBackup y luego esperaría a que finalice antes de ejecutar UNLOCK TABLES. Esto causó que la base de datos se bloqueara innecesariamente con FLUSH TABLES WITH READ LOCK. Innobackupex ahora solo espera hasta que finalice la copia de registro para desbloquear las bases de datos. Error solucionado # 1055989 (Alexey Kopytov).

Los mensajes de error
• innobackupex que hacen referencia al directorio de datos se han ampliado para mostrar la ruta del directorio de datos mencionado en el mensaje de error. Error solucionado # 1089375 (Hartmut Holzgraefe).
• Las tablas particionadas no fueron manejadas correctamente por las opciones --databases, --include, --tables-file de innobackupex, y por las opciones --tables y --tables-file de XtraBackup. Se corrigió eliminando el sufijo de partición (#P # ...) antes de filtrar. Error solucionado # 711166 (Sergei Glushchenko).
• Cuando se utilizaba la compresión incorporada, XtraBackup realizaba grabaciones sin búfer en el archivo o secuencia de destino en fragmentos muy pequeños que, a cambio, causaban E / S ineficaces. Se corrigió utilizando un búfer de 1M para una salida similar a las copias de seguridad sin comprimir. Error solucionado # 1095249 (Alexey Kopytov).
• Dormir innecesariamente () en el inobackupex lleva a que las MESAS DE FLUSH CON LEER BLOQUEO tarden demasiado. Se corrigió reemplazando 2 segundos de intervalo de sueño con 100 milisegundos. Error solucionado # 1095551 (Sergei Glushchenko).
• Si inobackupex se bloqueara, dejaría el archivo xtrabackup_suspended en el sistema de archivos. Esto podría hacer que innobackupex piense que XtraBackup se ha suspendido desde el momento en que comenzó, y luego cuando XtraBackup realmente se suspende, innobackupex esperaría a que terminara y no volvería a eliminar el archivo suspendido, lo que llevaría a un punto muerto de espera. Se corrigió al eliminar el archivo xtrabackup_suspended obsoleto cuando se iniciaba innobackupex. Error solucionado # 1007446 (George Ormond Lorch III).
• innobackupex no reconocería MariaDB 5.2 y MariaDB 5.3. Se corrigió mediante el aumento de las verificaciones de versión en innobackupex. Error solucionado # 733665 (Daniel van Eeden, Alexey Kopytov).
• Otras correcciones de errores: error corregido # 924492 (Alexey Kopytov), ​​error corregido # 1097158 (Alexey Kopytov), ​​error corregido # 1081882 (Alexey Kopytov), ​​error corregido # 1096584 (Alexey Kopytov).

Qué hay de nuevo en la versión 1.6.7:

• Errores solucionados:
• xtrabackup_binary no se incluyó en el archivo tar al transmitir, sino que se escribió en el directorio actual. Esto podría llevar a que se utilice un binario xtrabackup incorrecto al preparar copias de seguridad creadas con las opciones --stream o --remote-host. Errores corregidos # 723318 y # 787988 (Stewart Smith).
• FLUSH TABLES WITH READ LOCK no se usó al crear copias de seguridad incrementales, lo que podría generar copias de seguridad incoherentes cuando se produjeron actualizaciones en tablas que no son InnoDB o sentencias DDL en cualquier tabla durante el proceso de copia de seguridad. Error corregido # 771981 (Alexey Kopytov).
• Opción --safe-slave-backup estaba dando como resultado una información incorrecta de binlog, porque en algunos casos innobackupex confundió la respuesta de SHOW SLAVE STATUS con la de SHOW MASTER STATUS. Error solucionado # 977101 (Alexey Kopytov).
• innodb_data_file_path no se escribió en backup-my.cnf, esta fue una regresión introducida en XtraBackup 1.6.5. Error solucionado # 983685 (Sergei Glushchenko).
• Se corrigieron fallas en el conjunto de pruebas espurias con grep 2.10. Error solucionado # 996483 (Alexey Kopytov).
• Cuando se estaba ejecutando innobackupex con --apply-log, estaba leyendo la configuración del archivo de configuración del servidor en lugar de backup-my.cnf en el directorio de la copia de seguridad. Error solucionado # 996493 (Sergei Glushchenko).
• innobackupex podría copiar archivos en un directorio incorrecto al fusionar una copia de seguridad incremental con una completa. Error solucionado # 1002688 (Alexey Kopytov).
• XtraBackup binary estaba filtrando descriptores de archivo en --backup. Esto se solucionó reutilizando el descriptor de archivo existente para que no se produzca ninguna pérdida. Error solucionado # 713267 (Alexey Kopytov).

Qué hay de nuevo en la versión 2.0.4:

• Errores solucionados:
• La corrección de errores para # 932623 introdujo la regresión en XtraBackup 2.0.2 que causó el error de las copias de seguridad incrementales porque los valores de los parámetros init no estaban normalizados con los valores utilizados dentro de InnoDB. Error solucionado # 1062684 (Sergei Glushchenko).
• La corrección de errores para # 932623 introdujo la regresión en XtraBackup 2.0.2 porque no tomó el tablespace doublewrite por separado en una cuenta. Error solucionado # 1066843 (Sergei Glushchenko).
• XtraBackup manejaba incorrectamente el archivo de búfer de doble escritura separado. La ruta del archivo del búfer de escritura doble no se agregó a la copia de seguridad-mi.cnf y después de la restauración se usó el archivo de búfer de doble escritura en vez de uno hecho durante la etapa de preparación. Error solucionado # 1068470 (Sergei Glushchenko).
• XtraBackup ahora acepta la opción --innodb = force, anteriormente arrojaría un error si se establecía la opción. Error solucionado # 528752 (Laurynas Biveinis).
• La opción safe-slave-backup no funcionaba correctamente. Error solucionado # 887803 (Alexey Kopytov).
• En caso de que se llegara a safe-slave-backup-timeout al usar la opción safe-slave-backup, SQL_THREAD se dejó en estado detenido causando que el subproceso esclavo quede rezagado. Esto se solucionó comprobando el estado inicial de SQL_THREAD y comenzando antes de terminar con un error de tiempo de espera y comenzando el SQL_THREAD solo si se estaba ejecutando inicialmente. Error solucionado # 1037379 (Alexey Kopytov).
• XtraBackup fallaría en -apply-log cuando el sistema de archivos no admitía Linux AIO. Error solucionado # 1065561 (Alexey Kopytov).
• XtraBackup binary ignoraría innodb_use_native_aio cuando se especifica en my.cnf o como una opción de línea de comando. Error solucionado # 1068459 (Alexey Kopytov).
• XtraBackup imprimirá un mensaje de advertencia durante la etapa de preparación sobre innodb_file_io_threads en desuso, incluso si la variable no se configuró. Error solucionado # 1068485 (Alexey Kopytov).
• Las pruebas XtraBackup Galera ahora se pueden ejecutar al mismo tiempo. Error solucionado # 1077800 (Stewart Smith).

Qué hay de nuevo en la versión 2.0.3:

• Nuevas características:
• innobackupex ahora admite la opción new -move-back que se puede usar en lugar de -copy-back en caso de que no haya suficiente espacio libre en el disco en el servidor para copiar archivos. Como esta opción elimina los archivos de copia de seguridad, debe usarse con precaución.
• Errores solucionados:
• El enlace simbólico para el binario innobackupex-1.5.1 se ha roto en la versión anterior de XtraBackup. Error solucionado # 1038198 (Ignacio Nin).
• XtraBackup 2.0.2 no era compatible con versiones anteriores, lo que causaba que las copias de seguridad incrementales creadas con versiones anteriores fallaran en la preparación. Error solucionado # 1038127 (Sergei Glushchenko).
• La corrección para el error # 1022562 introdujo una regresión que potencialmente puede conducir a un aumento de 5x en el espacio en disco ocupado por copias de seguridad incrementales. Error solucionado # 1043762 (Laurynas Biveinis).
• Se introdujo una regresión en el arreglo para el error # 932623 que causó el manejo incorrecto de los espacios de tablas comprimidos con el tamaño de página de 16K, que se crearon entre el último respaldo completo o incremental y el siguiente respaldo incremental. Errores corregidos # 1049174 y # 1044398 (Laurynas Biveinis).

Novedades en la versión 1.6.4:

• Contiene correcciones de errores importantes para la serie estable 1.6 de versiones de Percona XtraBackup.