Это 21-й день моего участия в Gengwen Challenge, смотрите подробности мероприятия:Обновить вызов
Статьи по Теме
Сводка боя Redis:Редис в действии
предисловие
Редис этоБаза данных памяти, если вы не сохраните состояние базы данных в памяти на диск, состояние базы данных на сервере также исчезнет после выхода из серверного процесса. Итак, Redis предоставляетФункция сохранения !
1. RDB (база данных Redis)
①Сначала заходим на сервер, чтобы найти файл dump.rdb:
②Тест запускает операцию rdb: vim открывает файл конфигурации redis.conf
Для удобства тестирования мы изменили его на:
save 60 5 #意思是在60秒内进行了5次操作，即写入rdb文件中进行持久化保存
Как показано ниже:
③Спусковой механизм:
1. Когда правило сохранения выполняется, правило rdb будет автоматически запущено.Тест выглядит следующим образом:
Сначала вручную удалите файл dump.rdb, и эксперимент сработает!
Управляйте 5 командами в Redis!
Посмотрите, сгенерирован ли файл dump.rdb!
успех!
2. Выполните команду flushall, которая также активирует правило rdb.
Удалите файл dump.rdb еще раз!
Выполните команду операции flushall!
Нормальное поколение успешно!
3. Выход из Redis также активирует правила rdb
Удалить:
покидать:
Генерируется успешно!
④Восстановить файл rdb
1. Просто поместите резервный файл rdb в нашу стартовую директорию Redis, при запуске Redis автоматически проверит файл dump.rdb и восстановит в нем данные!
2. Команда для поиска местоположения файла:
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在 dump.rdb 文件，启动就会自动恢复其中的数据
⑤Преимущества и недостатки:
преимущество:
1, подходит для крупномасштабного восстановления данных!
2. Требования к целостности данных невысокие!
недостаток:
1, требуется определенный интервал времени в процессе работы! Если Redis неожиданно выйдет из строя, последние измененные данные будут потеряны!
2. При форк-процессе он будет занимать определенное пространство контента!
⑥Обзор:
Redis создаст (форкнет) отдельныйдочерний процессВ целях сохранения данные сначала будут записаны во временный файл.После завершения процесса сохранения временный файл будет использоваться для замены последнего постоянного файла. На протяжении всего процесса основным процессом являетсяНе выполнять никаких операций ввода-выводаиз. Это обеспечивает чрезвычайно высокую производительность. Если требуется крупномасштабное восстановление данных и целостность восстановления данных не очень чувствительна, метод RDB более эффективен, чем метод AOF. Недостатком RDB является то, что данные могут быть потеряны после последнего сохранения. По умолчанию используется RDB, в обычных условиях нет необходимости изменять эту конфигурацию!
Мы создадим резервную копию этого файла в производственной среде!
2. AOF (Добавить только файл)
① Redis по умолчанию использует режим RDB, поэтому вам нужно вручную включить режим AOF!
Это очень просто! Меняй нет на да!
Перезапустите сервер!
Найден новый файл appendonly.aof!
②содержимое файла:
Сначала сделайте несколько дополнений:
Затем мы можем открыть файл appendonly.aof с помощью vim, чтобы посмотреть, что внутри?
Обнаружения нет, в нем хранятся команды, которые мы использовали ранее!
③ Восстановите файл aof:
1. Если естькрутойМы модифицировали наш файл aof и добавили кое-что грязное, как нам это исправить? Как показано ниже:
2. Перезапустите Redis и увидите: Обнаружено, что перезагрузка не удалась! сообщить об ошибкеНе удалось загрузить информацию о конфигурации!
3. Мы можем использовать файл redis-check-aof, чтобы исправить это!
redis-check-aof --fix appendonly.aof #修复appendonly.aof文件
Вернитесь к успеху ремонта!
4. Давайте посмотрим на содержимое файла aof!
5. Внимательные учащиеся могут обнаружить, что, несмотря на меньшее количество неправильного содержания, существует также определенная потеря правильного содержания! Так что это исправление не может быть исправлением на 100%! Но выбросить малую часть и потерять все, дурак знает, что выбрать! хаха а!
6. Попробуйте перезапустить еще раз! успех!
④Переписать правила AOF!
По умолчанию aof является неограниченным добавлением файла, и файл будет становиться все больше и больше! Размер файла можно задать в файле конфигурации!
объяснять:
# appendfsync always # 每次修改都会 sync。消耗性能
appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！ # appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！
appendfilename "appendonly.aof" # 持久化的文件的名字
appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下， rdb完全够用！
auto-aof-rewrite-percentage 100 #写入百分比
auto-aof-rewrite-min-size 64mb #写入的文件最大值是多少，一般在实际工作中我们会将其设置为5gb左右！
⑤ Преимущества и недостатки!
преимущество:
1. Каждая модификация синхронизируется, и целостность файла будет лучше!
2. Синхронизируйте раз в секунду и потеряйте до одной секунды данных!
3. Никогда не синхронизируйтесь, самое эффективное!
недостаток:
1. По сравнению с файлами данных, aof намного больше, чем rdb, а скорость восстановления ниже, чем у rdb!
2. Aof также медленнее, чем rdb, поэтому конфигурация нашего redis по умолчанию — постоянство rdb!
⑥Суммировать: Ниже приводится резюме от великих пользователей сети!
1. Метод сохраняемости RDB может выполнять хранение моментальных снимков ваших данных в течение заданного интервала времени.
2. Метод сохраняемости AOF записывает каждую операцию записи на сервер. При перезапуске сервера эти команды будут выполняться повторно для восстановления исходных данных. Команда AOF добавляет и сохраняет каждую операцию записи в конец файла с помощью Redis. Redis также может перезаписывать файл AOF в фоновом режиме, чтобы размер файла AOF не был слишком большим.
3. Только кэш, если вы хотите, чтобы ваши данные существовали только при работающем сервере, вы также можете не использовать какое-либо сохранение.
4. Включите два метода сохранения одновременно
- В этом случае при перезапуске Redis он предпочтительно загрузит файл AOF для восстановления исходных данных, поскольку набор данных, сохраненный в файле AOF, обычно более полный, чем набор данных, сохраненный в файле RDB.
- Данные RDB не в режиме реального времени, и когда сервер перезагружается при одновременном использовании обоих, будут найдены только файлы AOF, поэтому следует ли нам использовать только AOF? Это не рекомендуется, потому что RDB больше подходит для резервного копирования баз данных (AOF постоянно меняется, и его непросто сделать резервную копию), быстрого перезапуска и потенциальных ошибок AOF не будет, поэтому держите его на всякий случай. кейсовый метод.
5. Предложения по производительности
- Поскольку файлы RDB используются только для целей резервного копирования, рекомендуется сохранять файлы RDB только на ведомом устройстве, и достаточно выполнять резервное копирование каждые 15 минут.Сохраняется только правило сохранения 900 1.
- Преимущество включения AOF состоит в том, что в худшем случае потеря данных будет не более двух секунд. Сценарий запуска проще и требует только загрузки собственного файла AOF. Цена заключается в том, что он обеспечивает непрерывный ввод-вывод и второй - перезапись AOF Наконец, блокировка, вызванная записью новых данных, сгенерированных в процессе перезаписи, в новый файл, почти неизбежна. Насколько позволяет жесткий диск, частота перезаписи AOF должна быть максимально снижена.Значение по умолчанию для базового размера перезаписи AOF составляет 64 М, что слишком мало. Его можно установить на значение более 5 ГБ. значение превышает 100% исходного размера и может быть изменено на соответствующее значение.
- Если вы не включите AOF, вы можете полагаться только на репликацию Master-Slave для достижения высокой доступности, что может сэкономить много операций ввода-вывода и уменьшить колебания системы во время перезаписи. Цена заключается в том, что если Master/Slave сливаются одновременно, данные будут потеряны более чем на десять минут.Сценарий запуска также должен сравнить файлы RDB в двух Master/Slave и загрузить более новый. это структура.
Впереди долгий путь, и я обязательно буду его искать вдоль и поперёк~
Если вы думаете, что я блогеры хорошо пишу! Писать нелегко, пожалуйста, ставьте лайки, подписывайтесь и комментируйте, чтобы поощрять блоггеров ~ хахах