web-dev-qa-db-fra.com

Quand est-il sûr de désactiver la mise en mémoire tampon double écriture d'InnoDB?

MySQL InnoDB nous permet de désactiver la mise en mémoire tampon en double écriture en définissant innodb_doublewrite = 0 . Autres bases de données ne semble pas permettre de modifier ce paramètre .

Comment InnoDB pourrait-il encore être en mesure de maintenir l'intégrité des données et ACIDE si nous désactivons mise en mémoire tampon en double écriture?

Dans quelles situations sera-t-il sûr de désactiver le tampon InnoDB doublewrite?

mysqlinnodblockingtransaction-logdata-integrity
7
Pacerier

La seule situation à laquelle je peux penser est le rechargement d'un grand mysqldump. Pourquoi ?

Découvrez cette représentation picturale d'InnoDB (Percona CTO Vadim Tkachenko)

InnoDB Architecture

Sur la photo, vous pouvez voir que le pool de tampons InnoDB écrit des pages sales dans

  • Tampon de journal
  • Insérer un tampon dans ibdata1
  • Double tampon d'écriture dans ibdata1
  • .ibd fichier pour chaque table InnoDB

La fermeture du double tampon d'écriture permettra à un mysqldump d'écrire des données et des pages d'index dans les tables plus rapidement car il n'a pas à écrire la même chose 16K pages à ibdata1.

Les serveurs de production ne doivent jamais désactiver le tampon d'écriture double. Si vous le faites pour charger les données plus rapidement (pendant la maintenance bien sûr), activez-les immédiatement après avoir rechargé le serveur DB.

En d'autres termes,

  • Ajouter innodb_doublewrite = 0 à my.cnf
  • Courir SET GLOBAL innodb_fast_shutdown = 0;
  • Redémarrez mysql
  • Charger mysqldump
  • Retirer innodb_doublewrite = 0 de my.cnf
  • Courir SET GLOBAL innodb_fast_shutdown = 0;
  • Redémarrez mysql
12
RolandoMySQLDBA

Cette question a été bien traitée dans this post par Yves Trudeau qui semble suggérer que c'est sûr - sa conclusion est que

Conclusion

Comme ZFS, ext4 peut être transactionnel et le remplacement du double tampon d'écriture InnoDB par le journal des transactions du système de fichiers entraîne une augmentation de 55% des performances pour une charge de travail intensive en écriture. Des gains de performances sont également attendus pour les configurations SSD et mixtes spinning/SSD

Il dit essentiellement que si vous avez un système de fichiers approprié, alors oui, cela peut être sûr.

Les gens de Percona connaissent vraiment leurs affaires.

8
Vérace

Mises à jour sur le blog Yves Trudeau: https://www.percona.com/blog/2015/06/17/update-on-the-innodb-double-write-buffer-and-ext4-transactions/ =

Bref, ce n'est probablement pas sûr.

Les commentaires semblent indiquer que - même s'il survivra à un test de tirage si le FS est ext4 avec journal, ou ZFS, il ne survivra pas à un simple kill (ou OOM I suspect) parce que le FS ne rejettera pas les données écrites partielles de la couche d'application.

4
HelloSam

Ma provisoire liste des situations où il est possible de désactiver le tampon de double écriture:

  • FusionIO (ou quel que soit son nom actuel) - Le lecteur le gère
  • Galera - Reconstruisez le nœud s'il se bloque
  • Esclaves - Reconstruisez l'esclave s'il se bloque
  • ZFS - Le pilote le gère
0
Rick James