Estas preguntas frecuentes proporcionan información sobre el motor de almacenamiento Aria.

los Aria El motor de almacenamiento se conocía anteriormente como Maria, (ver, el nombre de Aria). En las versiones actuales de MariaDB, puede referirse al motor como Maria o Aria. Como esto cambiará en versiones futuras, actualice las referencias en sus scripts y automatización para usar el nombre correcto.

¿Qué es Aria?

Aria es un motor de almacenamiento para MySQL® y MariaDB. Originalmente fue desarrollado con el objetivo de convertirse en el transaccional predeterminado. y motor de almacenamiento no transaccional para MariaDB y MySQL.

Ha estado en desarrollo desde 2007 y se anunció por primera vez en Monty’s Blog. Los mismos ingenieros centrales de MySQL que desarrollaron el servidor MySQL y los motores de almacenamiento MyISAM, MERGE y MEMORY también están trabajando en Aria.

¿Por qué el motor se llama Aria?

Originalmente, el motor de almacenamiento se llamaba Maria, después de la hija menor de Monty. Monty nombró a MySQL en honor a su primer hijo, Mi y su segundo hijo Max dio su nombre a MaxDB y las distribuciones MySQL-Max.

En la práctica, tener ambos MariaDB el servidor de la base de datos y Maria el motor de almacenamiento con nombres tan similares resultó confuso. Para mitigar esto, se tomó la decisión de cambiar el nombre. Durante el primer semestre de 2010 se llevó a cabo un concurso Rename Maria y se enviaron nombres de todo el mundo. Monty eligió el nombre Aria de una breve lista de finalistas. Chris Tooley, quien lo sugirió, recibió el premio de un Sistema 76 Meerkat NetTop del Programa Monty.

Para obtener más información, consulte el nombre de Aria.

¿Cuál es el objetivo de la versión actual?

La versión actual de Aria es 1.5. El objetivo de esta versión es desarrollar una alternativa segura a MyISAM. Es decir, cuando MariaDB se reinicia después de un bloqueo, Aria recupera todas las tablas al estado al comienzo de una declaración o al comienzo de la última LOCK TABLES declaración.

El objetivo actual es mantener el código estable y corregir todos los errores.

¿Cuál es el objetivo de la próxima versión?

La próxima versión de Aria es 2.0. El objetivo de esta versión es desarrollar un motor de almacenamiento totalmente transaccional con al menos todas las características principales de InnoDB.

Actualmente, Aria 2.0 está en espera ya que sus desarrolladores se están enfocando en mejorar MariaDB. Sin embargo, están interesados ​​en trabajar con clientes y socios interesados ​​para agregar más funciones a Aria y, finalmente, lanzar 2.0.

Estos son algunos de los objetivos de Aria 2.0:

  • Cumple con ACID
  • Confirmar / Revertir
  • Actualizaciones / eliminaciones simultáneas
  • Bloqueo de filas
  • Confirmación de grupo (ya en MariaDB 5.2)
  • Búsqueda más rápida en páginas de índice (directorio de páginas)

A partir de Aria 2.5, el plan es centrarse en mejorar el rendimiento.

¿Cuál es el objetivo final de Aria?

A largo plazo, tenemos los siguientes objetivos para Aria:

  • Para crear un nuevo motor de almacenamiento transaccional ACID y de control de concurrencia de múltiples versiones (MVCC) que pueda funcionar como motor de almacenamiento transaccional y no transaccional predeterminado para MariaDB y MySQL®.
  • Ser un reemplazo de MyISAM. Esto es posible porque Aria también se puede ejecutar en modo no transaccional, admite los mismos formatos de fila que MyISAM y admite o admitirá todas las funciones principales de MyISAM.
  • Ser el motor no transaccional predeterminado en MariaDB (en lugar de MyISAM).

¿Cuáles son los objetivos de diseño en Aria?

  • Control de simultaneidad de múltiples versiones (MVCC) y motor de almacenamiento ACID.
  • Opcionalmente, tablas no transaccionales que deberían ser ‘tan rápidas y compactas’ como las tablas MyISAM.
  • Poder usar Aria para tablas temporales internas en MariaDB (en lugar de MyISAM).
  • Todos los índices deben tener la misma velocidad (el índice agrupado no está en nuestra hoja de ruta actual para Aria. Si necesita un índice agrupado, debe usar XtraDB).
  • Permita que las transacciones de ‘cualquier’ longitud funcionen (tener transacciones de larga duración hará que se utilice más espacio de registro).
  • Permitir el envío de registros; es decir, puede realizar copias de seguridad incrementales de las tablas de Aria simplemente copiando los registros de Aria.
  • Permita la copia de tablas Aria entre diferentes servidores Aria (bajo algunas restricciones bien definidas).
  • Mejor manejo de blobs (que se ofrece actualmente en MyISAM, como mínimo).
  • Sin copia de memoria o memoria adicional utilizada para blobs al insertar / actualizar.
  • Blobs asignados en grandes bloques secuenciales: menos fragmentación a lo largo del tiempo.
  • Los blobs se almacenan para que Aria pueda extenderse fácilmente para tener acceso a cualquier parte de un blob con una única recuperación en el futuro.
  • Almacenamiento eficiente en disco (es decir, baja sobrecarga de datos de fila, baja sobrecarga de datos de página y poco espacio perdido en las páginas). Nota: Aún queda mucho trabajo por hacer para lograr este objetivo. El diseño del disco está bien, pero necesitamos más cachés en memoria para asegurarnos de obtener un factor de relleno más alto en las páginas.
  • Tamaño reducido, para que MariaDB + Aria sea adecuada para aplicaciones integradas y de escritorio.
  • Asignación de memoria flexible y algoritmos escalables para utilizar grandes cantidades de memoria de manera eficiente, cuando está disponible.

¿Dónde puedo encontrar documentación y ayuda sobre Aria?

La documentación está disponible en Aria y temas relacionados. El proyecto se mantiene en GitHub.

Si quieres saber qué sucede o ser parte del desarrollo de Aria, puedes suscribirte al maria-desarrolladores, maria-docs, o maria-discutir grupos en Launchpad.

Para informar y comprobar errores en Aria, consulte Informar errores.

Por lo general, puede encontrar algunos de los desarrolladores de Maria en línea en el canal de IRC #maria en freenode.

¿Quién desarrolla Aria?

El equipo central que desarrolla Aria es:

Líder técnico

  • Michael “Monty” Widenius – Creador de MySQL y MyISAM

Desarrolladores principales (en orden alfabético)

  • Guilhem Bichot: experto en replicación, respaldo en línea para MyISAM, etc.
  • Kristian Nielsen – Herramientas de compilación MySQL, NDB, servidor MySQL
  • Oleksandr Byelkin: caché de consultas, subconsultas, vistas.
  • Sergei Golubchik – Arquitecto de servidores, búsqueda de texto completo, claves para MyISAM-Merge, arquitectura de complementos, etc.

Todos excepto Guilhem Bichot están trabajando para MariaDB Corporation Ab.

¿Cuál es la política / programa de lanzamiento de Aria?

Aria sigue los mismos criterios de publicación que para MariaDB. Algunas aclaraciones, únicas para el motor de almacenamiento Aria:

  • Los formatos de archivo de datos e índices de Aria deben ser compatibles con versiones anteriores y posteriores para garantizar actualizaciones y degradaciones fáciles.
  • El formato del archivo de registro también debería ser compatible, pero todavía no ofrecemos ninguna garantía. En algunos casos, al actualizar, debe eliminar el antiguo aria_log.% y maria_log.% archivos antes de reiniciar MariaDB. (Hasta ahora, esto solo ha ocurrido en la actualización de MariaDB 5.1 y MariaDB 5.2).

Compromiso ampliado para Beta 1.5

  • Aria ahora tiene características completas de acuerdo con la especificación.

¿Cómo se compara Aria 1.5 con MyISAM?

Aria 1.0 era básicamente una versión no transaccional segura contra fallas de MyISAM. Aria 1.5 agregó más concurrencia (insertador múltiple) y algunas optimizaciones.

Aria es compatible con todos los aspectos de MyISAM, excepto como se indica a continuación. Esto incluye verificación / reparación / compresión externa e interna de filas, diferentes formatos de fila, diferentes formatos de compresión de índice, aria_chk etc. Después de un apagado normal, puede copiar archivos Aria entre servidores.

Ventajas de Aria en comparación con MyISAM

  • Los datos y los índices son seguros contra choques.
  • En caso de bloqueo, los cambios se revertirán al estado del inicio de una declaración o al último LOCK TABLES declaración.
  • Aria puede reproducir casi todo desde el registro. (Incluso CREATE, DROP, RENAME, TRUNCATE mesas). Por lo tanto, realiza una copia de seguridad de Aria simplemente copiando el registro. Las cosas que no se pueden reproducir (todavía) son:
    • Lote INSERT en una mesa vacía (esto incluye LOAD DATA INFILE, SELECT... INSERT y INSERT (muchas filas)).
    • ALTER TABLE. Tenga en cuenta que .frm ¡Las tablas NO se recrean!
  • LOAD INDEX puede omitir bloques de índice para índices no deseados.
  • Soporta todos MyISAM ROW formatos y nuevos PAGE formato donde los datos se almacenan en páginas. (el tamaño predeterminado es 8K).
  • Varios insertadores simultáneos en la misma tabla.
  • Cuando usas PAGE Los datos de fila de formato (predeterminado) se almacenan en caché por caché de página.
  • Aria tiene pruebas unitarias de la mayoría de las partes.
  • Admite tablas tanto a prueba de fallos (que pronto serán transaccionales) como no transaccionales. (Las tablas no transaccionales no se registran y las filas usan menos espacio): CREATE TABLE foo (...) TRANSACTIONAL=0|1 ENGINE=Aria.
  • PAGE es el único formato de fila transaccional / seguro contra fallas.
  • PAGE El formato debería proporcionar una mejora notable de la velocidad en los sistemas que tienen un almacenamiento en caché de datos incorrecto. (Por ejemplo, Windows).
  • Desde MariaDB 10.5, la longitud máxima de la clave es 2000 bytes, en comparación con 1000 bytes en MyISAM.

Diferencias entre Aria y MyISAM

  • Aria usa archivos de registro GRANDES (1G por defecto).
  • Aria tiene un archivo de control de registro (aria_log_control) y archivos de registro (aria_log.%). Los archivos de registro se pueden purgar automáticamente cuando no se necesitan o se pueden purgar a pedido (después de la copia de seguridad).
  • Aria usa páginas de 8K por defecto (MyISAM usa 1K). Esto hace que Aria sea un poco más rápido cuando se usan claves de tamaño fijo, pero más lento cuando se usan claves empaquetadas de longitud variable (hasta que agregamos un directorio a las páginas de índice).

Desventajas de Aria en comparación con MyISAM

  • Aria no es compatible INSERT DELAYED.
  • Aria no admite múltiples cachés de claves.
  • El almacenamiento de filas muy pequeñas (<25 bytes) no es eficiente para PAGE formato.
  • MERGE Las tablas no son compatibles con Aria (debería ser muy fácil de agregar más adelante).
  • Las páginas de datos Aria en formato de bloque tienen una sobrecarga de 10 bytes / página y 5 bytes / fila. La compatibilidad con transacciones y varios escritores simultáneos utilizará una sobrecarga adicional de 7 bytes para las filas nuevas, 14 bytes para las filas eliminadas y 0 bytes para las filas compactadas antiguas.
  • Sin bloqueo externo (MyISAM tiene bloqueo externo, pero esta es una función que se usa con poca frecuencia).
  • Aria tiene un tamaño de página tanto para el índice como para los datos (definido cuando se usa Aria por primera vez). MyISAM admite diferentes tamaños de página por índice.
  • Pequeña sobrecarga (15 bytes) por página de índice.
  • Aria no es compatible con RAID interno de MySQL (deshabilitado en MyISAM también, es una característica obsoleta).
  • El tamaño mínimo del archivo de datos para el formato PAGE es 16K (con 8K páginas).
  • Aria no admite índices en campos virtuales.

¿Diferencias entre la versión MariaDB 5.1 y la versión normal de MySQL-5.1?

Ver:

  • Motor de almacenamiento Aria

  • MariaDB frente a MySQL

¿Por qué usas el TRANSACTIONAL palabra clave ahora cuando Aria aún no es transaccional?

En la fase de desarrollo actual, las tablas Aria creadas con TRANSACTIONAL=1 son seguros y atómicos pero no transaccionales porque los cambios en las tablas Aria no se pueden revertir con el ROLLBACK mando. Como planeamos hacer que las tablas Aria sean completamente transaccionales, decidió que era mejor usar el TRANSACTIONAL palabra clave desde el principio para que las aplicaciones no tengan que cambiarse más tarde.

¿Cuáles son los problemas conocidos con la versión MySQL-5.1-Maria?

  • Ver KNOWN_BUGS.txt para errores abiertos / de diseño.
  • Consulte jira.mariadb.org para conocer los errores notificados recientemente. ¡Informe todo lo que no pueda encontrar aquí!
  • Si hay un error en el código de recuperación de Aria o en el código que genera los registros, o si los registros se corrompen, es posible que mysqld no se inicie porque Aria no puede ejecutar los registros al inicio.
  • La caché de consultas y la inserción simultánea con formato de fila de página tienen un error, desactive la caché de consulta mientras usa el formato de fila de página y MDEV-6817 no esta completo

Si Aria no se inicia o tiene una tabla irrecuperable (no debería suceder):

  • Eliminar el aria_log.% archivos del directorio de datos.
  • Reiniciar mysqld y correr CHECK TABLE, REPAIR TABLE o mysqlcheck en tus mesas Aria.

Alternativamente,

  • Eliminar registros y ejecutar aria_chk en tu *.MAI archivos.

¿Qué va a cambiar en las versiones principales posteriores de Aria?

los LOCK TABLES declaración no iniciará un segmento a prueba de accidentes. Deberías usar BEGIN y COMMIT en lugar de.

Para hacer que las cosas sean seguras en el futuro, puede hacer esto:

BEGIN;
LOCK TABLES ....
UNLOCK TABLES;
COMMIT;

Y luego puedes quitar el LOCK TABLES y UNLOCK TABLES declaraciones.

¿Cómo puedo crear una tabla similar a MyISAM (no transaccional) en Aria?

Ejemplo:

CREATE TABLE t1 (a int) ROW_FORMAT=FIXED TRANSACTIONAL=0 PAGE_CHECKSUM=0;
CREATE TABLE t2 (a int) ROW_FORMAT=DYNAMIC TRANSACTIONAL=0 PAGE_CHECKSUM=0;
SHOW CREATE TABLE t1;
SHOW CREATE TABLE t2;

Tenga en cuenta que las filas no se almacenan en caché en la caché de la página para FIXED o DYNAMIC formato. Si desea tener los datos almacenados en caché (algo que MyISAM no admite) debe usar ROW_FORMAT=PAGE:

CREATE TABLE t3 (a int) ROW_FORMAT=PAGE TRANSACTIONAL=0 PAGE_CHECKSUM=0;
SHOW CREATE TABLE t3;

Puedes usar PAGE_CHECKSUM=1 también para tablas no transaccionales; Esto coloca una suma de verificación de página en todas las páginas de índice. También coloca una suma de verificación en las páginas de datos si usa ROW_FORMAT=PAGE.

Es posible que aún tenga una diferencia de velocidad (puede ser ligeramente positiva o negativa) entre MyISAM y Aria debido a los diferentes tamaños de página. Puede cambiar el tamaño de página de MariaDB con --aria-block-size=#, dónde # es 1024, 2048, 4096, 8192, 16384 o 32768.

Tenga en cuenta que si cambia el tamaño de la página, debe volcar todas sus tablas antiguas en texto (con mysqldump) y elimine el registro y los archivos antiguos de Aria: 

# rm datadir/aria_log*

¿Cuáles son las ventajas / desventajas del nuevo PAGE formato en comparación con los antiguos formatos de fila similares a MyISAM (DYNAMIC y FIXED)

El tipo MyISAM DYNAMIC y FIXED Los formatos son extremadamente simples y tienen muy poca sobrecarga de espacio, por lo que es difícil superarlos cuando se trata de un escaneo simple de datos no modificados. los DYNAMIC Sin embargo, el formato empeora notablemente con el tiempo si actualiza mucho la fila de manera que aumente el tamaño de la fila.

Las ventajas del PAGE formato (comparado con DYNAMIC o FIXED) para tablas no transaccionales son:

  • Está almacenado en caché por la caché de página, que ofrece un mejor rendimiento aleatorio (ya que utiliza menos llamadas al sistema).
  • No se fragmenta tan fácilmente como el DYNAMIC formato durante UPDATE declaraciones. El número máximo de fragmentos es muy bajo.
  • El código se puede extender fácilmente para leer solo las columnas a las que se accede (por ejemplo, para omitir la lectura de blobs).
  • Actualizaciones más rápidas (en comparación con DYNAMIC).

Las desventajas son:

  • Ligera sobrecarga de almacenamiento (solo debe ser notable para tamaños de fila muy pequeños)
  • Tiempo de exploración de tabla completa más lento.
  • Cuando usas row_format=PAGE, (el valor predeterminado), Aria escribe primero la fila, luego las claves, momento en el que se realiza la comprobación de claves duplicadas. Esto hace PAGE formato más lento que DYNAMIC (o MyISAM) si hay muchas claves duplicadas debido a la sobrecarga de escribir y eliminar la fila. Si esto es un problema, puede usar row_format=DYNAMIC para obtener el mismo comportamiento que MyISAM.

¿Cuál es la forma correcta de copiar una tabla Aria de un lugar a otro?

Una tabla Aria consta de 3 archivos:

XXX.frm : The definition for the table, used by MySQL.
XXX.MYI : Aria internal information about the structure of the data and index and data for all indexes.
XXX.MAD : The data.

Es seguro copiar todos los archivos Aria a otro directorio o instancia de MariaDB si se cumple alguno de los siguientes:

  • Si apaga el servidor MariaDB correctamente con mysqladmin shutdown, para que Aria no tenga nada que recuperar cuando comience.

o

  • Si ha ejecutado un FLUSH TABLES declaración y no accedió a la tabla usando SQL desde ese momento hasta que las tablas hayan sido copiadas.

Además, debe cumplir la siguiente regla para las tablas transaccionales:

No puede copiar la tabla a una ubicación dentro del mismo servidor MariaDB si la nueva tabla ha existido antes y la nueva tabla todavía está activa en el registro de recuperación de Aria (es decir, es posible que Aria necesite acceder a los datos antiguos durante la recuperación). Si no está seguro de si existía el nombre anterior, ejecute aria_chk --zerofill sobre la mesa antes de usarlo.

Después de copiar una tabla transaccional y antes de usar la tabla, le recomendamos que ejecute el comando:

$ aria_chk --zerofill table_name

Esto sobrescribirá todas las referencias a los registros (LSN), todas las referencias transaccionales (TRN) y todo el espacio no utilizado con 0. También marca la tabla como “móvil”. Un beneficio adicional de zerofill es que los archivos Aria se comprimirán mejor. Nunca se eliminan datos reales como parte de zerofill.

Aria notará automáticamente si ha copiado una tabla de otro sistema y hará ‘zerofill’ para el primer acceso a la tabla si no estaba marcada como ‘movible’. La razón para usar aria_chk --zerofill es que evitas un retraso en el servidor MariaDB para el primer acceso a la tabla.

Tenga en cuenta que esta detección automática no funciona si copia tablas dentro del mismo servidor MariaDB.

¿Cuándo es seguro eliminar archivos de registro antiguos?

Si desea eliminar los archivos de registro de Aria (aria_log.%) con rm o eliminar, primero debe cerrar MariaDB limpiamente (por ejemplo, con mysqladmin shutdown) antes de eliminar los archivos antiguos.

Se aplican las mismas reglas al actualizar MariaDB; Al actualizar, primero elimine MariaDB de una manera limpia y luego actualice. Esto le permitirá eliminar los archivos de registro antiguos si hay problemas incompatibles entre versiones.

No quite el aria_log_control ¡expediente! Este no es un archivo de registro, sino un archivo que contiene información sobre la configuración de Aria (ID de transacción actual, ID único, siguiente número de archivo de registro, etc.).

Si lo hace, Aria generará un nuevo aria_log_control al inicio y considerará todos los archivos antiguos de Aria como archivos movidos desde otro sistema. Esto significa que deben ser “rellenados con cero” antes de que puedan utilizarse. Esto sucederá automáticamente en el próximo acceso a los archivos Aria, lo que puede llevar algún tiempo si los archivos son grandes.

Si esto sucede, verá cosas como esta en su archivo mysqld.err:

[Note] Zerofilling moved table: '.databasexxxx'

Como parte del zerofilling, no se eliminan datos vitales.

El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.