Comment utiliser les méthodes RDB et AOF de Redis

Solution de persistance Redis

Redis est une base de données en mémoire et les données sont stockées en mémoire Afin d'éviter une perte permanente de données due à la sortie du processus, les données dans Redis doivent être enregistrées de la mémoire sous une forme (données). ou commande) régulièrement sur le disque dur. Au prochain redémarrage de Redis, utilisez le fichier persistant pour récupérer les données. De plus, les fichiers persistants peuvent être copiés vers un emplacement distant à des fins de sauvegarde après sinistre.

Redis propose plusieurs niveaux différents de méthodes de persistance : l'une est RDB et l'autre est AOF.

La persistance RDB peut générer un instantané de l'ensemble de données dans un intervalle de temps spécifié et enregistrer l'instantané de la base de données sur le disque sous forme binaire.

AOF enregistre de manière persistante toutes les commandes d'opérations de modification exécutées par le serveur. Toutes les commandes du fichier AOF sont enregistrées au format du protocole Redis et les nouvelles commandes seront ajoutées à la fin du fichier. Redis peut également réécrire le fichier AOF en arrière-plan afin que la taille du fichier AOF ne dépasse pas la taille réelle requise pour enregistrer l'état de l'ensemble de données.

Redis peut utiliser la persistance AOF et la persistance RDB en même temps. Dans ce cas, au redémarrage de Redis, il donnera la priorité à l'utilisation du fichier AOF pour restaurer l'ensemble de données, car l'ensemble de données enregistré par le fichier AOF est généralement plus complet que l'ensemble de données enregistré par le fichier RDB. Vous pouvez même désactiver la persistance afin que les données n'existent que pendant l'exécution du serveur.

Il est très important de comprendre les similitudes et les différences entre la persistance RDB et la persistance AOF. Les sections suivantes présenteront en détail ces deux fonctions de persistance et expliqueront leurs similitudes et leurs différences.

Instantané RDB

Parlons de la première stratégie de persistance de Redis, l'instantané RDB. Redis prend en charge un mécanisme de persistance qui enregistre un instantané des données de mémoire actuelles dans un fichier de données. Comment une base de données écrite en continu génère-t-elle un instantané ? Redis utilise intelligemment le mécanisme de copie lors de l'écriture de la commande fork pour transférer le processus actuel dans un processus enfant. Le processus enfant conserve cycliquement les données dans des fichiers RDB en fonction de l'instantané de mémoire.

Par défaut, Redis enregistre l'instantané de la base de données dans un fichier binaire nommé dump.rdb dans le répertoire racine. Vous pouvez spécifier le répertoire de sauvegarde via la configuration du paramètre dir, et dbfilename spécifie le nom du fichier. Vous pouvez définir Redis, tel que "save N M", ce qui signifie que lorsqu'il y a M modifications dans les éléments de données dans un délai de N secondes, lorsque cette condition est remplie, l'ensemble de données sera automatiquement enregistré. Par exemple, vous pouvez configurer pour générer un instantané lorsqu'il y a 100 écritures en 10 minutes, ou vous pouvez configurer pour générer un instantané lorsqu'il y a 1 000 écritures en 1 minute. Il prend en charge plusieurs règles pour prendre effet en même temps, et lesquelles. la règle prendra effet lorsqu’elle correspondra. La définition de ces règles se trouve dans le fichier de configuration Redis. Vous pouvez également définir les règles pendant l'exécution de Redis via la commande Redis CONFIG SET sans redémarrer Redis.

Par exemple, le paramètre suivant amènera Redis à enregistrer automatiquement un ensemble de données lorsqu'il remplit la condition « au moins 1 000 clés ont été modifiées dans les 60 secondes » :

save 60 1000

Vous pouvez également l'enregistrer manuellement en appelant SAVE ou BGSAVE . Redis effectue des opérations de sauvegarde des ensembles de données. La commande SAVE effectue une opération de synchronisation et enregistre un instantané de toutes les données sous la forme d'un fichier RDB. La commande SAVE est rarement utilisée directement dans l'environnement de production car elle bloque toutes les requêtes client. Vous pouvez utiliser la commande BGSAVE à la place. La commande BGSAVE est exécutée en forçant un processus enfant, de sorte que la demande du client ne sera pas bloquée. Seul le fork du processus enfant bloquera le serveur. De plus, lors du déclenchement automatique de la persistance RDB, Redis choisira également BGSAVE au lieu de SAVE pour la persistance.

La persistance RDB automatique de Redis est implémentée en interne via la fonction de fonctionnement périodique du serveurCron, le compteur sale et l'horodatage de la dernière sauvegarde. ServerCron est exécuté toutes les 100 ms pour vérifier l'état du serveur, ce qui inclut la vérification si « save N M » remplit les conditions, et si c'est le cas, exécute BGSAVE, bien sûr, il inclut également la vérification de la réécriture AOF ; Le compteur sale est un état maintenu par le serveur Redis. Il enregistre combien de fois l'état du serveur a été modifié (y compris les ajouts, suppressions et modifications) depuis l'exécution de la dernière commande BGSAVE/SAVE. sale sera remis à 0. . L'horodatage de la dernière sauvegarde est également un état maintenu par le serveur Redis. Il enregistre l'heure à laquelle BGSAVE/SAVE a été exécuté avec succès. L'heure actuelle moins la dernière sauvegarde doit satisfaire M.

En plus des situations manuelles et automatiques, il existe d'autres situations qui déclencheront BGSAVE :

Dans le scénario de réplication maître-esclave, si le nœud esclave effectue une opération de copie complète, le nœud maître exécutera la commande BGSAVE et enverra le rdb vers le nœud esclave. Lors de l'exécution de la commande shutdown, la persistance RDB est automatiquement effectuée. De plus, vous devez comprendre que, comme l'opération d'écriture est effectuée dans un nouveau processus, lorsqu'un nouveau fichier RDB est généré, le processus enfant généré par Redis écrira d'abord les données dans un fichier temporaire, puis appellera le système de renommage atomique. Renommez le fichier temporaire en fichier RDB afin que si une panne se produit à tout moment, le fichier Redis RDB soit toujours disponible.

这种持久化方式被称为快照（snapshot）。但是，我们可以很明显的看到，RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，如果可以忍受间隔内数据丢失，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。但是对于另外一些对数据安全性要求极高的应用，无法容忍数据丢失的应用，RDB就无能为力了，所以Redis引入了另一个重要的持久化机制，AOF日志方式持久化。

为了尽可能使RDB文件体积减小，Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时，但是可以大大减小RDB文件的体积，因此压缩默认开启，参数为rdbcompression。需要注意的是，RDB文件的压缩并不是针对整个文件进行的，而是对数据库中的字符串进行的，且只有在字符串达到一定长度(20字节)时才会进行。

除了压缩，你也可以检验RDB文件，通过参数rdbchecksum设置，默认为yes。在写入文件和读取文件时都起作用，关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现。

另外，当bgsave出现错误时，Redis是否停止执行写命令。Redis提供了一个参数stop-writes-on-bgsave-error，设置为yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为no。

说说FORK的开销？

父进程通过fork操作可以创建子进程，第一代Unix系统实现了一种傻瓜式的进程创建：当执行fork系统调用时，内核复制父进程的整个用户空间并把复制得到的那一份分配给子进程。这种行为时非常耗时的，因为它需要完成以下几项任务：为子进程的页表分配页面、为子进程的页分配页面、初始化子进程的页表、把父进程的页复制到子进程对应的页中。

现在Linux的fork()使用写时拷贝（copy-on-write）页实现。写时拷贝是一种可以推迟甚至免除拷贝数据的技术。内核此时并不复制整个进程地址空间，而是让父进程和子进程共享同一个拷贝。只有在需要写入的时候，数据才会被复制，从而使各个进程拥有各自的拷贝。也就是说，资源的复制只有在需要写入的时候才进行，在此之前，只是以只读方式共享。这种技术使地址空间上的页的拷贝被推迟到实际发生写入的时候。所以就算fork很大内存的进程，对内存的消耗和耗时都很小。

现在虽然fork时，子进程不会复制父进程的数据空间，但是会复制内存页表（页表相当于内存的索引、目录）；父进程的数据空间越大，内存页表越大，fork时复制耗时也会越多。这个问题也是导致Redis内存不宜过大的原因之一，当然还有导致故障恢复时间延长也是Redis内存不宜过大的原因。

AOF日志

通过上面的分析，我们知道RDB快照有大概率丢失最近写入、且仍未保存到快照中的那些数据。尽管对于某些程序来说，数据安全并不是最重要的考虑因素，但是对于那些追求数据安全的程序来说，快照功能就不太适用了。从1.1版本开始，Redis增加了一种实时性更好的持久化方式，即AOF持久化。AOF日志的全称是append only file，从名字上我们就能看出来，它是一个追加写入的日志文件。与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

AOF文件与MySQL数据库的binlog不同的是，AOF是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点，它记录的内容就是一个个的Redis标准命令。开启AOF持久化命令如下：

appendonly yes
appendfilename "appendonly.aof"

从现在开始，每当Redis执行一个改变数据集的命令时（比如SET），这个命令就会被追加到AOF文件的末尾。这样的话，当Redis重新启时，程序就可以通过重新执行AOF文件中的命令来达到重建数据集的目的。

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程：

命令追加（append）

Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：

Afin d'améliorer l'efficacité de l'écriture des fichiers, dans les systèmes d'exploitation modernes, lorsque les utilisateurs appellent la fonction d'écriture pour écrire des données dans un fichier, le système d'exploitation stocke généralement temporairement les données dans une mémoire tampon lorsque la mémoire tampon est remplie ou dépasse la valeur spécifiée. délai, les données du tampon sont effectivement écrites sur le disque dur. Bien qu'une telle opération améliore l'efficacité, elle pose également des problèmes de sécurité : si l'ordinateur s'arrête, les données dans la mémoire tampon seront perdues, le système fournit également des fonctions de synchronisation telles que fsync et fdatasync, qui peuvent forcer le système d'exploitation à le faire ; transférez immédiatement les données dans le tampon vers Les données sont écrites sur le disque dur pour assurer la sécurité des données.

La stratégie du fichier de synchronisation de la zone de cache AOF est contrôlée par le paramètre appendfsync. La signification de chaque valeur est la suivante :

always : Immédiatement après l'écriture de la commande dans aof_buf, l'opération fsync du système est appelée pour se synchroniser avec le fichier. Fichier AOF. Une fois fsync terminé, le thread revient. Dans ce cas, chaque commande d'écriture doit être synchronisée avec le fichier AOF, et les E/S du disque dur deviennent un goulot d'étranglement en termes de performances. Redis ne peut prendre en charge qu'environ quelques centaines d'écritures TPS, ce qui réduit considérablement les performances de Redis, même en utilisant un disque SSD ( SSD), il ne peut gérer que des dizaines de milliers de commandes par seconde, et cela réduira considérablement la durée de vie du SSD.

non : Une fois la commande écrite dans aof_buf, l'opération d'écriture du système est appelée et la synchronisation fsync du fichier AOF n'est pas effectuée ; la synchronisation est gérée par le système d'exploitation et la période de synchronisation est généralement de 30 secondes. Dans ce cas, le temps de synchronisation des fichiers est incontrôlable, de nombreuses données s'accumuleront dans le tampon et la sécurité des données ne peut pas être garantie. Everysec : Une fois la commande écrite dans aof_buf, l'opération d'écriture du système est appelée. Le thread revient une fois l'écriture terminée ; l'opération du fichier de synchronisation fsync est appelée une fois par seconde par un thread dédié. Everysec est un compromis entre les deux stratégies susmentionnées, un équilibre entre performances et sécurité des données. Il s'agit donc de la configuration par défaut de Redis et de notre configuration recommandée.

Réécriture de fichier (réécriture)

Parce qu'AOF fonctionne en ajoutant continuellement des commandes à la fin du fichier, de sorte qu'à mesure que le nombre de commandes écrites continue d'augmenter, la taille du fichier AOF deviendra de plus en plus grande. Par exemple, si vous appelez INCR 100 fois sur un compteur, le fichier AOF doit utiliser 100 entrées uniquement pour enregistrer la valeur actuelle du compteur. Cependant, en réalité, l'utilisation d'une seule commande SET suffit à sauvegarder la valeur actuelle du compteur, et les 99 enregistrements restants sont en réalité redondants. De plus, certaines données expirées et données invalides peuvent également être supprimées.

Des fichiers AOF excessivement volumineux affecteront non seulement le fonctionnement normal du serveur, mais rendront également la récupération des données trop longue. Afin de gérer cette situation, Redis prend en charge une fonctionnalité intéressante qui permet de reconstruire le fichier AOF sans interrompre le client du service. Exécutez la commande BGREWRITEAOF, Redis générera un nouveau fichier AOF, qui contient les commandes minimales requises pour reconstruire l'ensemble de données actuel.

Le processus de génération AOF REWRITE (réécriture) est similaire à l'instantané RDB, qui utilisent tous deux intelligemment le mécanisme de copie sur écriture. Il crée également un processus enfant (le thread principal est bloqué à ce moment-là). Le processus enfant écrit dans le nouveau fichier AOF conformément à l'instantané de mémoire et aux règles de fusion des commandes. Lorsque le processus principal bifurque le thread enfant et continue d'accepter les demandes, toutes les commandes d'écriture sont toujours écrites dans le tampon AOF (aof_buf) et synchronisées sur le disque dur conformément à la politique appendfsync pour garantir l'exactitude du mécanisme AOF d'origine. Cependant, étant donné que l'opération fork utilise la technologie de copie sur écriture, le processus enfant ne peut partager les données de mémoire que pendant l'opération fork. Étant donné que le processus parent répond toujours à la commande, Redis utilise le tampon de réécriture AOF (aof_rewrite_buf) pour enregistrer cette partie du nouveau journal afin d'éviter que cette partie des données ne soit perdue lors de la génération du nouveau fichier AOF. En d'autres termes, lors de l'exécution de bgrewriteaof, la commande d'écriture Redis est ajoutée aux deux tampons aof_buf et aof_rewirte_buf en même temps.

Lorsque le processus enfant termine d'écrire le nouveau fichier AOF, il envoie un signal au processus parent, et le processus parent met à jour les informations statistiques, qui peuvent être consultées via la persistance des informations. Ensuite, le processus parent écrit les données du tampon de réécriture AOF dans le nouveau fichier AOF, garantissant ainsi que l'état de la base de données enregistré dans le nouveau fichier AOF est cohérent avec l'état actuel du serveur. Appelez ensuite la commande atomic rename pour remplacer l'ancien fichier AOF par le nouveau fichier AOF afin de terminer la réécriture AOF.

Vous devez faire attention ici car le processus principal ajoute le cache aof_rewrite_buf au nouveau fichier journal. Lorsque le processus principal ajoute des journaux, il ne traitera pas les autres requêtes. Si aof_rewrite_buf est particulièrement volumineux, par exemple des centaines de M, Redis peut ne pas répondre pendant plusieurs secondes, voire des dizaines de secondes.

D'après le processus ci-dessus, nous pouvons voir que les opérations RDB et AOF sont toutes deux des opérations d'E/S séquentielles et que leurs performances sont très élevées. Lors de la restauration de la base de données via des fichiers RDB ou des journaux AOF, les données sont également lues séquentiellement et chargées en mémoire. Cela ne provoquera donc pas de lecture aléatoire du disque.

Le déclenchement de la réécriture de fichiers est divisé en déclenchement manuel et déclenchement automatique :

Déclenchement manuel : Appelez directement la commande bgrewriteaof L'exécution de cette commande est quelque peu similaire à bgsave : les deux sous-processus fork effectuent un travail spécifique, et les deux le sont. effectué uniquement après le blocage du temps de fourchette.

Déclenchement automatique : déterminez le temps de déclenchement en fonction des paramètres auto-aof-rewrite-min-size et auto-aof-rewrite-percentage, ainsi que du statut aof_current_size et aof_base_size.

auto-aof-rewrite-min-size indique la taille minimale du fichier lors de la réécriture AOF. La valeur par défaut est de 64 Mo.

auto-aof-rewrite-percentage表示执行AOF重写时，当前AOF大小（即aof_current_size）和上一次重写时AOF大小（aof_base_size）的比值，即增长比例达到设定值。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

其中，参数可以通过config get命令查看：

127.0.0.1:6391> CONFIG GET auto-aof-rewrite-min-size
1) "auto-aof-rewrite-min-size"2) "64000000"127.0.0.1:6391> CONFIG GET auto-aof-rewrite-percentage
1) "auto-aof-rewrite-percentage"2) "100"

状态可以通过info persistence查看：

127.0.0.1:6379> info persistence# Persistenceaof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_current_size:40876638
aof_base_size:2217565
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0

另外在aof rewrite过程中，是否采取增量”文件同步”策略，由参数aof-rewrite-incremental-fsync控制，默认为”yes”，而且必须为yes。rewrite过程中，每32M数据进行一次文件同步，这样可以减少”aof大文件”写入对磁盘的操作次数。

bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。

如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候Redis挂掉，就会丢失数据。丢失多少数据呢？在Linux的操作系统的默认设置下，最多会丢失30s的数据。因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

AOF刷新策略？

前面提到过，在AOF中，如果AOF缓冲区的文件同步策略为everysec，则：在主线程中，命令写入aof_buf后调用系统write操作，write完成后主线程返回；fsync同步文件操作由专门的文件同步线程每秒调用一次。这种做法的问题在于，如果硬盘负载过高，那么fsync操作可能会超过1s；如果Redis主线程持续高速向aof_buf写入命令，硬盘的负载可能会越来越大，IO资源消耗更快；如果此时Redis进程异常退出，丢失的数据也会越来越多，可能远超过1s。

为此，Redis的处理策略是这样的：主线程每次进行AOF会对比上次fsync成功的时间；如果距上次不到2s（也就是延迟了1s），主线程直接返回；如果超过2s，则主线程阻塞直到上一次fsync同步完成。因此，如果系统硬盘负载过大导致fsync速度太慢，会导致Redis主线程的阻塞；此外，使用everysec配置，AOF最多可能丢失2s的数据，而不是1s。具体看Redis AOF刷新策略分析

AOF追加阻塞问题定位的方法，监控info Persistence中的aof_delayed_fsync，当AOF追加阻塞发生时（即主线程等待fsync而阻塞），该指标累加。另外，AOF阻塞时的Redis日志：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

如果AOF追加阻塞频繁发生，说明系统的硬盘负载太大；可以考虑更换IO速度更快的硬盘，或者通过IO监控分析工具对系统的IO负载进行分析。

对于pipelining有什么不同？

对于pipelining的操作，其具体过程是客户端一次性发送N个命令，然后等待这N个命令的返回结果被一起返回。通过采用pipilining就意味着放弃了对每一个命令的返回值确认。由于在这种情况下，N个命令是在同一个执行过程中执行的。所以当设置appendfsync为everysec时，可能会有一些偏差，因为这N个命令可能执行时间超过1秒甚至2秒。但是可以保证的是，最长时间不会超过这N个命令的执行时间和。

如果AOF文件出错了，怎么办？

服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成了 AOF 文件出错（corrupt），那么Redis在重启时会拒绝载入这个AOF文件， 从而确保数据的一致性不会被破坏。当发生这种情况时，可以用以下方法来修复出错的 AOF 文件：为现有的AOF文件创建一个备份。然后使用Redis附带的redis-check-aof –fix程序对原来的AOF文件进行修复。

然后可选使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。再次重启Redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。

Mais si la fin du fichier AOF est incomplète (un temps d'arrêt soudain de la machine peut facilement rendre la fin du fichier incomplète) et que le paramètre aof-load-truncated est activé, un avertissement sera affiché dans le journal, et Redis ignorera la fin du fichier AOF et démarrera avec succès. Le paramètre aof-load-truncated est activé par défaut.

Avantages et inconvénients du RDB et de l'AOF

Avantages du RDB ?

RDB est un fichier très compact avec une petite taille et une transmission réseau rapide. Il enregistre l'ensemble de données Redis à un moment donné. Ce type de fichier est très adapté à la sauvegarde et la vitesse de récupération est beaucoup plus rapide que celle de l'AOF. Bien entendu, l’un des avantages les plus importants du RDB est qu’il a un impact relativement faible sur les performances par rapport à l’AOF. La seule chose que le processus parent doit faire lors de la sauvegarde du fichier RDB est de débourser un processus enfant, puis le processus enfant gérera tous les travaux de sauvegarde ultérieurs. Le processus parent n'a pas besoin d'effectuer d'opérations d'E/S sur disque.

Inconvénients du RDB ?

Le défaut fatal des fichiers RDB est que la méthode de persistance des instantanés de données détermine que la persistance en temps réel ne peut pas être obtenue. Aujourd'hui, alors que les données deviennent de plus en plus importantes, une grande quantité de perte de données est souvent inacceptable, c'est pourquoi la persistance AOF. devenir courant. De plus, les fichiers RDB doivent répondre à un format spécifique et avoir une mauvaise compatibilité (par exemple, l'ancienne version de Redis n'est pas compatible avec la nouvelle version des fichiers RDB).

Avantages d'AOF ?

Correspondant à la persistance RDB, l'avantage d'AOF est qu'il prend en charge la persistance de deuxième niveau et a une bonne compatibilité. Vous pouvez définir différentes politiques fsync, telles que pas de fsync, fsync chaque seconde ou fsync à chaque fois qu'une commande d'écriture est exécutée. La politique par défaut d'AOF est fsync une fois par seconde. Dans cette configuration, Redis peut toujours maintenir de bonnes performances, et même en cas de panne, une seule seconde de données sera perdue au maximum. Le fichier AOF est un fichier journal qui effectue uniquement des opérations d'ajout (ajout uniquement au journal), donc l'écriture dans le fichier AOF ne nécessite pas de recherche, même si le journal contient des commandes incomplètes pour certaines raisons (telles que l'écriture. Le disque est plein, l'écriture est arrêté pendant l'écriture, etc.), l'outil redis-check-aof peut également résoudre facilement ce problème.

Redis peut réécrire automatiquement l'AOF en arrière-plan lorsque la taille du fichier AOF devient trop grande : le nouveau fichier AOF réécrit contient l'ensemble minimum de commandes requis pour restaurer l'ensemble de données actuel. L'ensemble de l'opération de réécriture est absolument sûr, car Redis continuera à ajouter des commandes au fichier AOF existant pendant le processus de création d'un nouveau fichier AOF. Même en cas d'arrêt pendant le processus de réécriture, le fichier AOF existant ne sera pas perdu. . Une fois le nouveau fichier AOF créé, Redis passera de l'ancien fichier AOF au nouveau fichier AOF et commencera à l'ajouter au nouveau fichier AOF. Le fichier AOF enregistre toutes les opérations d'écriture effectuées sur la base de données de manière ordonnée. Ces opérations d'écriture sont enregistrées au format du protocole Redis, le contenu du fichier AOF est donc très facile à lire et il est facile d'analyser le fichier ( analyser). Exporter (exporter) des fichiers AOF est également très simple : par exemple, si vous exécutez accidentellement la commande FLUSHALL, mais tant que le fichier AOF n'a pas été écrasé, alors arrêtez simplement le serveur, supprimez la commande FLUSHALL à la fin de l'AOF et redémarrez Redis. Vous pouvez restaurer l'ensemble de données à l'état avant l'exécution de FLUSHALL.

Inconvénients d'AOF ?

La taille des fichiers AOF est généralement plus grande que celle des fichiers RDB et la vitesse de récupération est lente. Pour le même ensemble de données, AOF peut être plus lent que RDB selon la stratégie fsync utilisée. Dans des circonstances normales, les performances de fsync par seconde sont toujours très élevées, et la désactivation de fsync peut rendre AOF aussi rapide que RDB. De plus, AOF a eu un tel bug dans le passé. En raison de certaines commandes, lorsque le fichier AOF est rechargé, l'ensemble de données ne peut pas être restauré à son état d'origine lors de sa sauvegarde. Bien que ce type de bug ne soit pas courant dans les fichiers AOF, en comparaison, il est presque impossible que ce type de bug se produise dans RDB.

RDB et AOF, lequel dois-je utiliser ?

Tout d'abord, vous devez comprendre que qu'il s'agisse de RDB ou d'AOF, l'activation de la persistance a un coût en termes de performances : pour la persistance RDB, d'une part, le processus principal Redis sera bloqué lorsque bgsave effectue une opération fork, et d'un autre côté, le processus enfant L'écriture de données sur le disque dur entraînera également une pression d'E/S. Mais si l’entreprise peut tolérer une perte de données de quelques minutes à 10 minutes (et n’utilise pas de base de données de secours), RDB est un bon choix, sinon choisissez AOF ;

Pour la persistance AOF, la fréquence d'écriture des données sur le disque dur est considérablement augmentée (deuxième niveau sous la politique Everysec) et la pression d'E/S est plus grande, ce qui peut même provoquer un problème de blocage d'ajout d'AOF (ce blocage sera décrit en détail plus tard ). De plus, la réécriture des fichiers AOF est similaire à celle de bgsave de RDB, et il y aura des problèmes de blocage lors du fork et de la pression des E/S sur le processus enfant. Relativement parlant, étant donné qu'AOF écrit plus fréquemment des données sur le disque dur, cela aura un plus grand impact sur les performances du processus principal Redis.

在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一种，或同时开启RDB和AOF持久化等。此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能，而且主机master和从机slave可以独立的选择持久化方案。比如完全关闭master持久化（包括RDB和AOF），这样可以让master的性能达到最好；而slave可以只开启AOF。但这种情况下，如果master服务因为故障宕掉了，如果系统中有自动拉起机制（即检测到服务停止后重启该服务）将master自动重启，由于没有持久化文件，那么master重启后数据是空的，slave同步数据也变成了空的，意味着数据丢失。所以尽量避免这种情况出现。

RDB和AOF之间的相互作用？

在版本号大于等于2.4的Redis中，BGSAVE执行的过程中，不可以执行BGREWRITEAOF。反过来说，在BGREWRITEAOF执行的过程中，也不可以执行BGSAVE。这可以防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果BGSAVE正在执行，并且用户显示地调用BGREWRITEAOF命令，那么服务器将向用户回复一个OK状态，并告知用户，BGREWRITEAOF已经被预定执行： 一旦BGSAVE执行完毕，BGREWRITEAOF就会正式开始。当Redis启动时，如果RDB持久化和AOF持久化都被打开了，那么程序会优先使用AOF文件来恢复数据集，因为AOF文件所保存的数据通常是最完整的。

RDB和AOF数据导入

这些持久化的数据有什么用，当然是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB或AOF进行恢复的时候，会读取RDB或AOF文件，重新加载到内存中。相对于MySQL等数据库的启动时间来说，会长很多，因为MySQL本来是不需要将数据加载到内存中的。

但是相对来说，MySQL启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，通常我们称之为预热，而在预热完成前，其性能都不会太高。而Redis的好处是一次性将数据加载到内存中，一次性预热。这样只要Redis启动完成，那么其提供服务的速度都是非常快的。

而在利用RDB和利用AOF启动上，其启动时间有一些差别。RDB的启动时间会更短，原因有两个，一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作。在CPU消耗上要远小于AOF日志的加载。

注意：当redis启动时，如果rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了，则启动之后数据库内容为空。

注意：如果想把正在运行的redis数据库，从RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。(不能直接修改配置文件，重启数据库，否则数据库中数据就为空了。) 在Redis 2.2或以上版本，可以在不重启的情况下，从RDB切换到AOF ：

为最新的dump.rdb文件创建一个备份，将备份放到一个安全的地方。执行以下两条命令：

127.0.0.1:6379> CONFIG SET dir /apps/redis/data/redis-8836
127.0.0.1:6379> CONFIG SET appendonly yes
127.0.0.1:6379> CONFIG SET save ""

确保命令执行之后，数据库的键的数量没有改变。确保写命令会被正确地追加到 AOF 文件的末尾。

步骤2是开启了AOF功能，Redis会阻塞直到初始AOF文件创建完成为止，之后Redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾。

步骤3用于关闭RDB功能，这一步是可选的，如果你愿意的话，也可以同时使用RDB和AOF这两种持久化功能。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!