table des matières
Préface
Lorsque nous configurons la réplication maître-esclave MySQL, en plus des paramètres de configuration nécessaires, ces deux paramètres sont souvent configurés: innodb_flush_log_at_trx_commit
et sync_binlog. Jetons un coup d'œil au rôle de ce paramètre.
innodb_flush_log_at_trx_commit
Lors de la validation de la transaction, écrivez le journal de rétablissement sur le disque. Ce que l'on appelle le journal de rétablissement sert à enregistrer les modifications que vous avez apportées aux données. Par exemple, si vous remplacez la valeur du champ de nom par "id = 10", ceci est un journal. Si nous voulons valider une transaction, nous viderons le journal de restauration du tampon de journalisation vers le fichier disque selon une certaine stratégie. À ce stade, cette stratégie est configurée via innodb_flush_log_at_trx_commit, et elle a plusieurs options.
La valeur est 0: lorsque la transaction est validée, les données du tampon de journalisation ne sont pas immédiatement vidées dans le fichier disque, mais le thread principal d'InnoDB est vidé sur le disque toutes les secondes. À ce stade, vous pouvez valider la transaction, et par conséquent, mysql est en panne et toutes les données de la mémoire sont perdues.
La valeur est 1: lors de la validation d'une transaction, vous devez vider le journal de restauration de la mémoire vers le fichier disque. Tant que la transaction est validée avec succès, le journal de restauration doit être sur le disque. Notez qu'en raison de la fonctionnalité «écriture différée» du système d'exploitation, le clignotement à ce moment est uniquement écrit dans la mémoire tampon du système d'exploitation, de sorte que l'opération de synchronisation peut garantir qu'il doit être conservé sur le disque dur.
Valeur 2: lors de la validation de la transaction, écrivez le journal de rétablissement dans le cache du système d'exploitation correspondant au fichier disque au lieu d'entrer directement dans le fichier disque. L'écriture des données du cache du système d'exploitation dans le fichier disque peut prendre 1 seconde.
On peut voir que seulement 1 peut vraiment garantir la durabilité de la transaction, mais comme l'opération de rafraîchissement fsync () est bloquée et ne revient pas tant qu'elle n'est pas terminée, nous savons que la vitesse d'écriture sur le disque est très lente, donc les performances de MySQL seront en déclin évident. Si vous ne vous souciez pas de la perte de transaction, 0 et 2 peuvent obtenir de meilleures performances.
# 查询
select @@innodb_flush_log_at_trx_commit;
sync_binlog
Ce paramètre contrôle le processus d'écriture des journaux binaires sur le disque.
Les valeurs valides de ce paramètre sont 0, 1, N:
0：默认值。事务提交后，将二进制日志从缓冲写入磁盘，但是不进行刷新操作（fsync()），此时只是写入了操作系统缓冲，若操作系统宕机则会丢失部分二进制日志。
1：事务提交后，将二进制文件写入磁盘并立即执行刷新操作，相当于是同步写入磁盘，不经过操作系统的缓存。
N：每写N次操作系统缓冲就执行一次刷新操作。
La définition de ce paramètre sur une valeur supérieure à 1 améliorera les performances de la base de données, mais cela s'accompagnera également d'un risque de perte de données.
Les fichiers journaux binaires impliquent la récupération de données, et si vous souhaitez obtenir une cohérence maximale entre le maître et l'esclave, vous devez définir ce paramètre sur 1, mais cela entraînera également une certaine perte de performances.