{"id":21539,"date":"2026-09-19T08:33:36","date_gmt":"2026-09-19T06:33:36","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/"},"modified":"2026-09-19T08:33:36","modified_gmt":"2026-09-19T06:33:36","slug":"mariadb-metodos-de-vaciado-innodb-fsync-guia-de-rendimiento-bufer","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/","title":{"rendered":"Comparaci\u00f3n de los m\u00e9todos de vaciado de MariaDB: configuraci\u00f3n \u00f3ptima de \u00abinnodb flush\u00bb"},"content":{"rendered":"<p>Comparo los m\u00e9todos m\u00e1s importantes para <strong>MariaDB Flush<\/strong> y te muestro c\u00f3mo configuro \u00abinnodb flush\u00bb para reducir la latencia de escritura y garantizar la seguridad de los datos. Me centrar\u00e9 en las opciones de innodb_flush_method, el controlador de durabilidad innodb_flush_log_at_trx_commit, as\u00ed como en los valores recomendados para las p\u00e1ginas sucias y la capacidad de E\/S en discos duros, SSD y NVMe.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>innodb_flush_method<\/strong> Determina c\u00f3mo interact\u00faa InnoDB con la cach\u00e9 del sistema operativo y evita el doble almacenamiento en cach\u00e9.<\/li>\n  <li><strong>innodb_flush_log_at_trx_commit<\/strong> Establece la duraci\u00f3n frente a la latencia por cada confirmaci\u00f3n.<\/li>\n  <li><strong>P\u00e1ginas sucias<\/strong> y la capacidad de E\/S suaviza las tasas de escritura y evita las oleadas de vaciado.<\/li>\n  <li><strong>Vecinos de color<\/strong> distingue entre estrategias optimizadas para discos duros (HDD) y estrategias optimizadas para SSD\/NVMe.<\/li>\n  <li><strong>Configuraciones en la nube<\/strong> requieren O_DIRECT, un l\u00edmite adecuado de IOPS y una supervisi\u00f3n rigurosa.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-flush-0123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00bfQu\u00e9 significa concretamente \u00abinnodb_flush_method\u00bb?<\/h2>\n\n<p>Elijo el <strong>M\u00e9todo Flush<\/strong> depende de c\u00f3mo InnoDB interact\u00faa con la cach\u00e9 del sistema operativo. Con <strong>fsync<\/strong> Los datos se almacenan primero en la cach\u00e9 del sistema operativo y luego se escriben de forma permanente mediante fsync; esto puede provocar un doble almacenamiento en cach\u00e9. Si configuro O_DIRECT, InnoDB evita en gran medida la cach\u00e9 de p\u00e1ginas, lo que ahorra RAM y casi siempre resulta beneficioso en SSD\/NVMe. O_DSYNC utiliza la escritura directa (write-through) y reduce el almacenamiento en b\u00fafer, lo que puede resultar \u00fatil en combinaciones espec\u00edficas. O_DIRECT_NO_FSYNC se basa en O_DIRECT y ajusta el comportamiento de sincronizaci\u00f3n, lo que constituye una opci\u00f3n muy v\u00e1lida en hardware fiable que cuente con su propio mecanismo de protecci\u00f3n.<\/p>\n\n<h3>Valores y versiones habituales<\/h3>\n\n<p>A partir de MariaDB 10.6, <strong>O_DIRECTO<\/strong> A menudo es la configuraci\u00f3n predeterminada, ya que evita el doble almacenamiento en cach\u00e9. En versiones anteriores predomina <strong>fsync<\/strong>, lo que a\u00fan puede resultar aceptable para configuraciones con discos duros. A partir de la versi\u00f3n 11.0, otras variables como innodb_data_file_buffering e innodb_log_file_buffering controlan los detalles del almacenamiento en b\u00fafer. En la pr\u00e1ctica, innodb_flush_method sigue siendo el par\u00e1metro clave que compruebo en primer lugar. A continuaci\u00f3n, voy ajustando los par\u00e1metros detallados hasta que las latencias disminuyen y el rendimiento se mantiene constante.<\/p>\n\n<h2>Utilizar \u00abinnodb_flush_log_at_trx_commit\u00bb de forma selectiva<\/h2>\n\n<p>Considero que <strong>Durabilidad<\/strong> y la latencia por separado, ya que innodb_flush_log_at_trx_commit determina ambas cosas. El valor 1 escribe y ejecuta fsync en cada commit, lo que ofrece la m\u00e1xima seguridad, pero ralentiza considerablemente los discos lentos. El valor 2 escribe en la cach\u00e9 del sistema operativo al realizar un commit y ejecuta fsync aproximadamente una vez por segundo; esto reduce la latencia, pero conlleva el riesgo de perder hasta un segundo de datos en caso de corte de corriente. El valor 0 pospone las operaciones de escritura del registro por completo a intervalos de un segundo y ofrece el m\u00e1ximo rendimiento de escritura con el mayor riesgo. Si adem\u00e1s se tiene en cuenta la estrategia del registro binario (binlog), se pueden adaptar de forma inteligente las latencias de confirmaci\u00f3n a los requisitos de replicaci\u00f3n; explico aqu\u00ed los detalles de esta interacci\u00f3n: <a href=\"https:\/\/webhosting.de\/es\/logica-de-rendimiento-de-los-registros-binarios-de-mariadb\/\">Registros binarios<\/a>.<\/p>\n\n<h2>Gestionar el vaciado de la cach\u00e9 y las p\u00e1ginas sucias<\/h2>\n\n<p>Considero que el porcentaje de <strong>P\u00e1ginas sucias<\/strong> de modo que las tasas de escritura se mantengan constantes. Para ello, configuro innodb_max_dirty_pages_pct en un valor moderado, para evitar que se produzcan picos repentinos de flushing. Ajusto los valores de innodb_io_capacity e innodb_io_capacity_max en funci\u00f3n de las IOPS reales del almacenamiento: bajos para HDD y m\u00e1s altos para SSD\/NVMe. Un hilo de limpieza de p\u00e1ginas bien configurado escribe a tiempo, seg\u00fan el criterio LRU, antes de que las p\u00e1ginas sean desplazadas. Aqu\u00ed describo con m\u00e1s detalle el ajuste fino de los hilos y las m\u00e9tricas m\u00e1s \u00fatiles: <a href=\"https:\/\/webhosting.de\/es\/mariadb-limpiador-de-paginas-subprocesos-base-de-datos\/\">Hilos de Page Cleaner<\/a>.<\/p>\n\n<h2>Flush-Neighbors: HDD frente a SSD\/NVMe<\/h2>\n\n<p>Con <strong>innodb_flush_neighbors<\/strong> Utilizo patrones de escritura que protegen el disco duro o los desactivo. En los discos duros (HDD), la escritura simult\u00e1nea de p\u00e1ginas adyacentes mejora la eficiencia, ya que el cabezal tiene que desplazarse menos. En los SSD\/NVMe, la ubicaci\u00f3n en el soporte apenas es relevante; en estos casos, la escritura simult\u00e1nea genera operaciones de escritura innecesarias. Para los discos duros, suelo establecer el valor 1; para los SSD\/NVMe, el valor 0. De esta forma, reduzco las operaciones de escritura superfluas y prolongo la vida \u00fatil de las unidades de mayor velocidad.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_flush_vergleich_7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprender y limitar los costes de fsync<\/h2>\n\n<p>Mido el <strong>fsync<\/strong>-Latencia, porque cada milisegundo ralentiza las confirmaciones. De lo contrario, las cargas de trabajo con gran volumen de escritura pasan gran parte del tiempo esperando la confirmaci\u00f3n del dispositivo de almacenamiento. Con innodb_flush_log_at_trx_commit=2 o 0, reduzco considerablemente el n\u00famero de sincronizaciones costosas. O_DIRECT u O_DIRECT_NO_FSYNC ayudan a evitar el doble almacenamiento en cach\u00e9 y a simplificar las rutas de E\/S. En equipos lentos, a menudo obtengo una mejora notable si analizo conjuntamente la frecuencia de sincronizaci\u00f3n, el m\u00e9todo de vaciado y la cuota de p\u00e1ginas sucias.<\/p>\n\n<h2>Valores iniciales recomendados seg\u00fan el soporte de almacenamiento<\/h2>\n\n<p>Empiezo con cosas que tienen sentido <strong>L\u00ednea de base<\/strong>-Valores y, a continuaci\u00f3n, los ajusto en funci\u00f3n de los valores medidos. La tabla ofrece orientaciones para configuraciones y cargas de trabajo t\u00edpicas. Los factores decisivos son las IOPS reales, las latencias y el porcentaje de transacciones de escritura. Tras la primera ejecuci\u00f3n, compruebo la tasa de p\u00e1ginas sucias, la latencia de confirmaci\u00f3n y el n\u00famero de llamadas a fsync. A continuaci\u00f3n, voy ajustando poco a poco hasta que el perfil se mantenga limpio y constante.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Medio<\/th>\n      <th>innodb_flush_method<\/th>\n      <th>innodb_flush_log_at_trx_commit<\/th>\n      <th>innodb_io_capacity<\/th>\n      <th>innodb_flush_neighbors<\/th>\n      <th>Notas<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>HDD<\/td>\n      <td>fsync u O_DIRECT<\/td>\n      <td>1 (cr\u00edtico) \/ 2 (equilibrio)<\/td>\n      <td>200\u2013400<\/td>\n      <td>1<\/td>\n      <td>M\u00e1s latencia por <strong>Compromiso<\/strong>, es importante realizar un lavado continuo<\/td>\n    <\/tr>\n    <tr>\n      <td>SSD<\/td>\n      <td>O_DIRECTO<\/td>\n      <td>1 (cr\u00edtico) \/ 2 (equilibrio)<\/td>\n      <td>1000\u20132000<\/td>\n      <td>0<\/td>\n      <td>Evitar el doble almacenamiento en cach\u00e9 y mantener un n\u00famero moderado de p\u00e1ginas sucias<\/td>\n    <\/tr>\n    <tr>\n      <td>NVMe<\/td>\n      <td>O_DIRECT u O_DIRECT_NO_FSYNC<\/td>\n      <td>1 (cr\u00edtico) \/ 2 (equilibrio) \/ 0 (caso especial)<\/td>\n      <td>2000\u20138000+<\/td>\n      <td>0<\/td>\n      <td>Muy bajo <strong>Latencia<\/strong>, Elegir cuidadosamente la frecuencia de sincronizaci\u00f3n<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>A este respecto, tengo en cuenta InnoDB <strong>B\u00fafer de doble escritura<\/strong>, que reduce la corrupci\u00f3n de datos en caso de fallos del sistema, pero genera escrituras adicionales; a continuaci\u00f3n resumo de forma concisa los antecedentes y las opciones de ajuste: <a href=\"https:\/\/webhosting.de\/es\/innodb-doble-bufer-de-escritura-seguridad-optimizacion-del-rendimiento-enfoque\/\">B\u00fafer de doble escritura<\/a>. En entornos con un uso intensivo de la escritura, realizo mediciones con y sin efectos de doble escritura antes de tomar decisiones. Los sistemas cr\u00edticos dan prioridad a la integridad frente a la velocidad m\u00e1xima de escritura. Las configuraciones de prueba o de an\u00e1lisis pueden ser m\u00e1s agresivas. Siempre respaldo mis decisiones con pruebas de rendimiento repetibles.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-flush-methoden-vergleich-5876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Entornos de nube y contenedores<\/h2>\n\n<p>Evito las repeticiones <strong>Cach\u00e9 de p\u00e1gina<\/strong>, porque all\u00ed la RAM es escasa; por eso, O_DIRECT suele ser una buena opci\u00f3n. Ajusto el valor de innodb_io_capacity a los l\u00edmites de IOPS del volumen para no provocar una limitaci\u00f3n de rendimiento. El pool de b\u00faferes debe ajustarse al l\u00edmite del cgroup; de lo contrario, se corre el riesgo de que se produzcan terminaciones por falta de memoria (OOM). Los vol\u00famenes persistentes son imprescindibles, ya que el almacenamiento ef\u00edmero no ofrece durabilidad. En configuraciones muy el\u00e1sticas, limito el n\u00famero excesivo de conexiones simult\u00e1neas y utilizo el pool de subprocesos de forma prudente.<\/p>\n\n<h2>Configuraci\u00f3n de \u00abBackup\u00bb y \u00abFlush\u00bb<\/h2>\n\n<p>Compruebo si las herramientas de copia de seguridad tienen sus propias <strong>Descarga<\/strong>-Utilizar los ajustes. mariadb-backup puede establecer un valor diferente para innodb_flush_method con el fin de obtener una visi\u00f3n coherente. Si los par\u00e1metros de la copia de seguridad y del servidor no coinciden, se producen picos de E\/S innecesarios. Durante las copias de seguridad programadas, regulo con cuidado la capacidad de E\/S para que las rutas de lectura y escritura se mantengan limpias. Una vez finalizada la operaci\u00f3n, compruebo las latencias y el porcentaje de p\u00e1ginas sucias para descartar efectos secundarios.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-flush-optimal-3435.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>El tuning paso a paso en la pr\u00e1ctica<\/h2>\n\n<p>Empiezo con un <strong>Inventario<\/strong>: Tipo de almacenamiento, IOPS reales, latencias y rendimiento. A continuaci\u00f3n, establezco el tama\u00f1o del pool de b\u00faferes, ajust\u00e1ndolo a la RAM disponible o al l\u00edmite de Cgroup. Despu\u00e9s, selecciono el m\u00e9todo de vaciado (HDD: fsync\/O_DIRECT; SSD\/NVMe: O_DIRECT u O_DIRECT_NO_FSYNC). En cuanto a la durabilidad, configuro innodb_flush_log_at_trx_commit en 1 para datos cr\u00edticos o en 2 si es aceptable una p\u00e9rdida de un segundo. Por \u00faltimo, configuro innodb_io_capacity e innodb_max_dirty_pages_pct de manera que el vaciado se realice de forma fluida y constante, y compruebo las m\u00e9tricas con regularidad.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-flush-vergleich-8243.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionar correctamente el tama\u00f1o del registro de rehacer y los puntos de control<\/h2>\n\n<p>Evito los picos de flujo ajustando el <strong>Registros de rehacer<\/strong> Dimensionarlos adecuadamente. Los archivos de registro demasiado peque\u00f1os obligan a InnoDB a realizar puntos de control con frecuencia; esto provoca contrapresi\u00f3n y latencias inestables. Con archivos de registro m\u00e1s grandes, suavizo el proceso de los puntos de control, ya que se pueden almacenar en el b\u00fafer m\u00e1s datos de modificaci\u00f3n antes de que se vean obligados a trasladarse a los archivos de datos. Para ello, tengo en cuenta dos l\u00edmites: en primer lugar, la capacidad de E\/S disponible (un b\u00fafer grande no protege contra discos demasiado lentos); en segundo lugar, el tiempo de recuperaci\u00f3n tras un fallo, que aumenta con los registros de redo muy grandes. En cargas de trabajo con un uso intensivo de escritura, configuro el tama\u00f1o del registro de modo que los picos de carga t\u00edpicos se absorban dentro del presupuesto de registro, sin que el tiempo de recuperaci\u00f3n aumente de forma desproporcionada.<\/p>\n\n<p>Para realizar ajustes precisos, superviso las m\u00e9tricas relativas a la \u201eantig\u00fcedad de los puntos de control\u201c y la relaci\u00f3n entre la tasa de escritura en el registro y la tasa de vaciado de las p\u00e1ginas de datos. Si los puntos de control alcanzan repetidamente el l\u00edmite m\u00e1ximo, ampl\u00edo el tama\u00f1o del registro o aumento con cautela la capacidad de E\/S del \u00abpage cleaner\u00bb. El objetivo es lograr un avance suave y continuo de los puntos de control sin necesidad de intervenciones forzadas.<\/p>\n\n<h2>Purga adaptativa y valores umbral<\/h2>\n\n<p>Los mecanismos adaptativos de InnoDB ayudan a vaciar la memoria en el momento actual <strong>Velocidad de escritura<\/strong> ajustar. Me aseguro de que el umbral LWM (Low Watermark) para las p\u00e1ginas sucias no sea demasiado bajo, para que el \u201epage cleaner\u201c no funcione constantemente \u201eal l\u00edmite\u201c. Al mismo tiempo, evito valores m\u00e1ximos que provoquen vaciados masivos demasiado agresivos. En la pr\u00e1ctica, compruebo si la relaci\u00f3n entre las \u201enuevas p\u00e1ginas sucias por segundo\u201c y las \u00abIOPS de vaciado\u00bb se mantiene estable a largo plazo. Si el pool de b\u00faferes se ensucia constantemente por encima del objetivo, aumento gradualmente el valor de innodb_io_capacity o reduzco los objetivos de p\u00e1ginas sucias.<\/p>\n\n<p>En configuraciones NVMe puedo dar m\u00e1s margen al \u00abpage cleaner\u00bb, ya que los dispositivos mantienen latencias bajas incluso bajo carga. En los discos duros (HDD) utilizo umbrales m\u00e1s conservadores y limito las oscilaciones bruscas para evitar picos de latencia debidos a los movimientos de lectura\/escritura. La interacci\u00f3n con <strong>innodb_flush_neighbors<\/strong> Lo utilizo de forma espec\u00edfica: el disco duro se beneficia de la proximidad f\u00edsica, mientras que la memoria flash no.<\/p>\n\n<h2>La interacci\u00f3n entre Binlog y Group-Commit<\/h2>\n\n<p>Quien utilice la replicaci\u00f3n, tiene en cuenta eso <strong>Registro de confirmaciones<\/strong> Sobre el redo log y el binario log. Configuro las frecuencias de vaciado de tal forma que se aplique el \u00abgroup commit\u00bb: se deben vaciar juntas muchas transacciones peque\u00f1as, en lugar de sincronizar cada \u00abcommit\u00bb por separado. Para ello, se recomienda innodb_flush_log_at_trx_commit=1 para una durabilidad m\u00e1xima o 2 para una latencia menor. Paralelamente, configuro el mecanismo de sincronizaci\u00f3n del binlog para que se adapte al sistema de destino. Una frecuencia de sincronizaci\u00f3n baja reduce los costes por commit, pero puede suponer una mayor p\u00e9rdida de registros binarios en caso de fallo del sistema. En entornos con una alta tasa de escritura y un retraso tolerable entre el maestro y la r\u00e9plica, acepto un desacoplamiento moderado de las sincronizaciones del binlog para reducir las latencias. La l\u00f3gica general y las compensaciones las expongo en la entrada sobre <a href=\"https:\/\/webhosting.de\/es\/logica-de-rendimiento-de-los-registros-binarios-de-mariadb\/\">Registros binarios<\/a> y luego la adapto al perfil concreto de la cisterna.<\/p>\n\n<h2>Sistema de archivos, cach\u00e9 de escritura y protecci\u00f3n contra cortes de corriente<\/h2>\n\n<p>Califico el <strong>Caracter\u00edsticas de la memoria y del controlador<\/strong> antes del ajuste. Dispositivos con <em>Protecci\u00f3n contra p\u00e9rdidas de potencia<\/em> (PLP) pueden utilizar las cach\u00e9s de escritura de forma segura; sin PLP, existe el riesgo de que las escrituras que se han notificado como confirmadas se pierdan en caso de corte de corriente. En tales casos, opto por una actitud m\u00e1s conservadora: las rutas fsync siguen siendo obligatorias, y solo utilizo O_DIRECT_NO_FSYNC en hardware con una protecci\u00f3n fiable. En sistemas de archivos de Linux como ext4 o XFS, las barreras se consideran activas por defecto; no las desactivo a la ligera, sino que ajusto la configuraci\u00f3n en torno a las garant\u00edas existentes. En ZFS, tengo en cuenta adem\u00e1s su propio \u00abIntent Log\u00bb y sus estrategias de almacenamiento en cach\u00e9; dependiendo de la configuraci\u00f3n, merece la pena aplicar una estrategia ajustada por separado que minimice tambi\u00e9n el doble almacenamiento en cach\u00e9.<\/p>\n\n<p>Para garantizar un rendimiento constante, compruebo adem\u00e1s las alineaciones (por ejemplo, p\u00e1ginas de 4K en SSD) y la negociaci\u00f3n de la profundidad de la cola. Las latencias cortas y deterministas suelen ser m\u00e1s importantes para las rutas de confirmaci\u00f3n que el n\u00famero m\u00e1ximo de IOPS en pruebas sint\u00e9ticas. Por eso realizo pruebas con bloques realistas y niveles de concurrencia, en lugar de limitarme \u00fanicamente a cargas de trabajo m\u00e1ximas.<\/p>\n\n<h2>Metodolog\u00eda de medici\u00f3n: m\u00e9tricas, estado y diagn\u00f3stico<\/h2>\n\n<p>Controlo la puesta a punto a trav\u00e9s de <strong>valores de medici\u00f3n concretos<\/strong> en lugar de basarme en las sensaciones. Entre mis indicadores habituales se encuentran:<\/p>\n<ul>\n  <li>Latencia de confirmaci\u00f3n (p50\/p95\/p99) durante los picos de carga<\/li>\n  <li>Latencia y frecuencia de fsync para archivos de registro y de datos<\/li>\n  <li>Porcentaje de p\u00e1ginas con contenido inapropiado a lo largo del tiempo y su variaci\u00f3n<\/li>\n  <li>Progreso de los puntos de control y relaci\u00f3n entre la tasa de escritura en el registro y la tasa de vaciado<\/li>\n  <li>Pendientes de Page Cleaner (\u00bfhay constantemente operaciones de vaciado pendientes?)<\/li>\n<\/ul>\n<p>Para ello, utilizo los mensajes de estado de InnoDB y los correlaciono con las m\u00e9tricas del sistema operativo (iostat, vmstat). En concreto, observo la latencia del disco en milisegundos y la distribuci\u00f3n entre lecturas y escrituras, as\u00ed como el porcentaje de operaciones sincr\u00f3nicas. Para que las pruebas sean reproducibles, var\u00edo de forma selectiva solo un par\u00e1metro por paso y registro el resultado durante intervalos prolongados, para que los valores at\u00edpicos no predominen.<\/p>\n\n<h2>Anti-patrones frecuentes y medidas para evitarlos<\/h2>\n\n<ul>\n  <li>Registros \u00abredo\u00bb demasiado peque\u00f1os: provocan puntos de control frecuentes. Soluci\u00f3n: aumentar el tama\u00f1o de los registros y ajustar la capacidad de E\/S para el vaciado.<\/li>\n  <li>El porcentaje de p\u00e1ginas sucias se mantiene demasiado alto: el \u00abPage Cleaner\u00bb est\u00e1 sobrecargado y existe riesgo de que se produzcan \u00abtormentas de flush\u00bb. Medida correctiva: reducir el valor de \u00abinnodb_max_dirty_pages_pct\u00bb y aumentar el de \u00abio_capacity\u00bb.<\/li>\n  <li>O_DIRECT sin supervisi\u00f3n: aunque evita el doble almacenamiento en cach\u00e9, puede provocar picos de actividad si la capacidad de E\/S es incorrecta. Soluci\u00f3n: supervisi\u00f3n rigurosa y vinculaci\u00f3n de los valores de capacidad a los IOPS reales.<\/li>\n  <li>Los \u00abflush-neighbors\u00bb inadecuados en SSD\/NVMe: generan una carga de trabajo adicional sin aportar ning\u00fan beneficio. Soluci\u00f3n: establecer innodb_flush_neighbors=0.<\/li>\n  <li>Sincronizaciones de confirmaci\u00f3n en soportes lentos: cada transacci\u00f3n paga el precio de fsync. Medida correctiva: fomentar el Group-Commit; si es necesario, innodb_flush_log_at_trx_commit=2 (tras evaluar los riesgos).<\/li>\n  <li>Contenedores sin b\u00fafer de RAM: el grupo de b\u00faferes es demasiado grande, existe riesgo de OOM. Medida correctiva: ajustar estrictamente el grupo de b\u00faferes a los l\u00edmites del Cgroup y supervisar la presi\u00f3n.<\/li>\n<\/ul>\n\n<h2>Tener en cuenta las rutas de apagado y recuperaci\u00f3n<\/h2>\n\n<p>Estoy analizando c\u00f3mo influyen los ajustes en <strong>Apagado<\/strong> y <strong>Recuperaci\u00f3n tras un fallo<\/strong> repercute. Un apagado r\u00e1pido y limpio reduce los tiempos de recuperaci\u00f3n, ya que hay que aplicar menos operaciones de redo. Los registros de redo muy grandes favorecen los puntos de control tranquilos, pero, en caso de error, alargan el proceso de recuperaci\u00f3n. Para los sistemas en producci\u00f3n, elijo el equilibrio de tal forma que, por un lado, no genere picos de flushing en la actividad diaria y, por otro, en el peor de los casos, no tenga que aceptar una recuperaci\u00f3n excesivamente larga. Tengo en cuenta las ventanas de mantenimiento y las copias de seguridad desde el principio.<\/p>\n\n<h2>Recetas pr\u00e1cticas para cargas de trabajo t\u00edpicas<\/h2>\n\n<ul>\n  <li>OLTP con muchos commits peque\u00f1os en SSD\/NVMe: O_DIRECT, innodb_flush_log_at_trx_commit=1 o 2 seg\u00fan la durabilidad, innodb_io_capacity m\u00e1s bien alto, Dirty-Pages moderado, Flush-Neighbors=0. Utilizar activamente el \u00abBinlog Group Commit\u00bb.<\/li>\n  <li>Importaci\u00f3n por lotes con gran volumen de escritura: aumentar ligeramente el objetivo de p\u00e1ginas sucias de forma temporal, incrementar la capacidad de E\/S y volver a los valores anteriores una vez finalizada la operaci\u00f3n. Si la durabilidad es aceptable, establecer temporalmente innodb_flush_log_at_trx_commit=2.<\/li>\n  <li>Sistemas heredados basados en discos duros (HDD): capacidad de E\/S conservadora, Flush-Neighbors=1, innodb_flush_method=fsync u O_DIRECT, en funci\u00f3n de la presi\u00f3n sobre la memoria RAM. Se debe prestar especial atenci\u00f3n al vaciado continuo para evitar picos de b\u00fasqueda.<\/li>\n  <li>Vol\u00famenes en la nube con presupuesto de IOPS: vincular innodb_io_capacity estrictamente al l\u00edmite garantizado, evitar picos de actividad y utilizar O_DIRECT para ahorrar RAM. En los sistemas de cr\u00e9ditos (E\/S en r\u00e1fagas), utilizo el control de ritmo (pacing) para que el presupuesto no se agote de golpe.<\/li>\n<\/ul>\n\n<h2>Lista de comprobaci\u00f3n para la resoluci\u00f3n de problemas<\/h2>\n\n<ul>\n  <li>\u00bfLatencias prolongadas en los commits del p95? Comprueba la duraci\u00f3n de fsync, activa Group-Commit y, si es necesario, reduce la frecuencia de vaciado (tras evaluar los riesgos).<\/li>\n  <li>\u00bfGran variaci\u00f3n en el porcentaje de p\u00e1ginas sucias? Ajusta con precisi\u00f3n los par\u00e1metros io_capacity\/io_capacity_max y comprueba los umbrales de vaciado adaptativo.<\/li>\n  <li>\u00bfPicos repentinos de latencia durante las copias de seguridad? Sincroniza los par\u00e1metros de la herramienta de copias de seguridad y los valores del servidor, y ajusta temporalmente la limitaci\u00f3n de E\/S.<\/li>\n  <li>\u00bfLa r\u00e9plica va con retraso? Eval\u00faa conjuntamente la estrategia de vaciado del binlog, las frecuencias de sincronizaci\u00f3n y la latencia de la red; las sincronizaciones demasiado agresivas ralentizan el servidor maestro.<\/li>\n  <li>\u00bfPresi\u00f3n en la RAM tras el cambio a O_DIRECT? Reajustar el equilibrio entre el pool de b\u00faferes y la cach\u00e9 del sistema operativo; O_DIRECT reduce la cach\u00e9 del sistema operativo, pero puede afectar a la cach\u00e9 de p\u00e1ginas de la aplicaci\u00f3n.<\/li>\n<\/ul>\n\n<h2>Breve resumen<\/h2>\n\n<p>Organizo el <strong>Estrategia de \u00abflush\u00bb<\/strong> siempre est\u00e1 supeditado al hardware y a los objetivos de durabilidad. O_DIRECT evita el doble almacenamiento en cach\u00e9 y suele ofrecer los mejores resultados en SSD\/NVMe. El par\u00e1metro innodb_flush_log_at_trx_commit determina la velocidad por commit y el riesgo en caso de corte de corriente. Unos valores bien elegidos para Dirty Pages, capacidad de E\/S y Flush-Neighbors mantienen constantes las tasas de escritura. Quien, adem\u00e1s, mida los costes de fsync y respete los l\u00edmites de la nube, conseguir\u00e1 que MariaDB funcione a pleno rendimiento de forma fiable, sin sacrificar la seguridad.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprende a configurar de forma \u00f3ptima los m\u00e9todos de vaciado de MariaDB y el vaciado de InnoDB con O_DIRECT, fsync e innodb_flush_log_at_trx_commit. Esta gu\u00eda te muestra t\u00e9cnicas pr\u00e1cticas de optimizaci\u00f3n de bases de datos para entornos HDD, SSD y en la nube, centr\u00e1ndose en el rendimiento y la seguridad de los datos.<\/p>","protected":false},"author":1,"featured_media":21532,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21539","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"66","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Flush","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21532","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21539","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21539"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21539\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21532"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}