Что такое настойчивость?
Постоянство можно резюмировать одним предложением: сохранение данных (например, объектов в памяти) на запоминающих устройствах, которые можно сохранить навсегда. Основное применение персистентности — хранение объектов в памяти в базах данных или в дисковых файлах, файлах данных XML и т. д.
Понимание персистентности на уровне приложений и системном уровне
В то же время постоянство можно понять и на прикладном уровне, и на системном уровне:
прикладной уровень: если выключен(Close
) ваше приложение, а затем перезапустите предыдущие данные все еще там.
системный слой: если выключен(Shutdown
) ваша система (компьютер), а затем перезагрузите предыдущие данные все еще существуют.
Почему Redis постоянен?
Все типы данных в Redis поддерживают push/pop, add/remove, объединение пересечений и разность и более сложные операции, и эти операции являются атомарными. Исходя из этого, Redis поддерживает сортировку различными способами. Как и Memcached, данные кэшируются в памяти для обеспечения эффективности.
Да, данные кэшируются в памяти.При перезапуске или выключении системы данные, кэшированные в памяти, исчезают и их невозможно найти снова. Поэтому, чтобы хранить данные долго, необходимо хранить данные, которые Redis помещает в кеш, как постоянное хранилище.
Как Redis достигает постоянства?
В начале разработки Redis учел эту проблему. Официальный предоставляет множество различных уровней методов сохранения данных:
1. Метод сохраняемости RDB может сохранять моментальные снимки ваших данных через определенные промежутки времени.
2. Метод сохраняемости AOF записывает каждую операцию записи на сервер.При перезапуске сервера эти команды выполняются повторно для восстановления исходных данных.Команда AOF добавляет протокол redis для сохранения каждой операции записи в конец файла. Redis также может перезаписывать файл AOF в фоновом режиме, чтобы размер файла AOF не был слишком большим.
3. Если вы хотите, чтобы ваши данные существовали только во время работы сервера, вы также не можете использовать какой-либо метод сохранения.
4. Вы также можете включить два метода сохранения одновременно.В этом случае, когда Redis перезапустится, файл AOF будет загружен первым для восстановления исходных данных, потому что набор данных, сохраненный файлом AOF, обычно выше, чем у набор данных, сохраненный в файле, должен быть полным.
Если вы не знаете, какой уровень настойчивости выбрать, давайте сначала разберемся, в чем разница между методом AOF и методом RDB, и каковы их преимущества и недостатки.После изучения давайте рассмотрим, какой из видов уровней выбрать.
Преимущества RDB и AOF
Сначала давайте посмотрим на официальное описание преимуществ двух методов и проведем сравнение, а затем посмотрим на описание недостатков двух методов.
Преимущества подхода RDB
-
RDB — это очень компактный файл, он сохраняет набор данных в определенный момент времени, он очень подходит для резервного копирования набора данных, например, вы можете сохранить данные за последние 24 часа в каждом почасовом отчете и сохранить прошлые Данные за 30 дней каждый день, так что даже если что-то пойдет не так, вы сможете восстановить другую версию набора данных в соответствии с вашими потребностями.
-
RDB — это компактный отдельный файл, который легко переносится в другой удаленный центр обработки данных, что идеально подходит для аварийного восстановления.
-
Когда RDB сохраняет файлы RDB, единственное, что нужно сделать родительскому процессу, — это разветвить дочерний процесс, а дочерний процесс выполняет всю следующую работу Родительскому процессу не нужно выполнять другие операции ввода-вывода, поэтому метод сохраняемости RDB может максимизировать производительность Redis.
-
По сравнению с AOF метод RDB будет быстрее при восстановлении больших наборов данных.
Когда Redis нужно сохранитьdump.rdb
файл, сервер делает следующее:
- Redis вызывает форки, у него есть как родительские, так и дочерние процессы.
- Подпроцесс записывает набор данных во временный файл RDB.
- Когда дочерний процесс завершает запись в новый файл RDB, Redis заменяет старый файл RDB новым файлом RDB и удаляет старый файл RDB.
Этот способ работы позволяет Redis копировать при записи (copy-on-write
) механизм.
Использование AOF сделает ваш Redis более надежным:Преимущества метода АОФ
-
Вы можете использовать разные стратегии fsync: без fsync, fsync в секунду, fsync при каждой записи.Со стратегией fsync по умолчанию по умолчанию Redis по-прежнему работает хорошо (fsync обрабатывается фоновым потоком, а основной поток делает все возможное для обработки клиента). запросы), в случае сбоя вы потеряете до 1 секунды данных.
-
Файл AOF представляет собой файл журнала только для добавления, поэтому нет необходимости искать запись, даже если полная команда записи не выполняется по какой-либо причине (дисковое пространство заполнено, сбой во время записи и т. д.), вы все равно можете использовать инструмент redis-check-aof для устранения этих проблем.
-
Redis может автоматически перезаписывать AOF в фоновом режиме, когда размер файла AOF становится слишком большим: новый файл AOF после перезаписи содержит минимальный набор команд, необходимых для восстановления текущего набора данных. Вся операция перезаписи абсолютно безопасна, поскольку Redis продолжит добавлять команды к существующему файлу AOF в процессе создания нового файла AOF.Даже если во время процесса перезаписи произойдет отключение, существующий файл AOF не будет потерян. . После создания нового файла AOF Redis переключится со старого файла AOF на новый файл AOF и начнет добавление к новому файлу AOF.
-
Файл AOF сохраняет все операции записи, выполняемые в базу данных, в упорядоченном порядке, и эти операции записи сохраняются в формате протокола Redis, поэтому содержимое файла AOF очень легко читается людьми, а файл анализируется (
parse
) тоже легко. экспорт (export
) файл AOF тоже очень прост: например, если вы случайно выполнили команду FLUSHALL, но пока файл AOF не перезаписан, то просто остановите сервер, удалите команду FLUSHALL в конце файла AOF и перезапустите Redis, вы можете. Набор данных восстанавливается до состояния, в котором он находился до выполнения FLUSHALL.
Резюме сравнения преимуществ
Метод RDB может сохранять данные за прошедший период времени, и в результате получается один файл, резервная копия которого может быть скопирована на другие серверы, а при ответе на большой объем данных скорость метода RDB будет выше. чем метод АОФ.
Метод AOF по умолчанию выполняет резервное копирование один раз в секунду, и частота очень высока.Его метод работы заключается в записи журналов вместо данных дополнительным способом, а процесс перезаписи заключается в последовательном добавлении, поэтому содержимое файла очень легко читается. . . . Вы можете открыть файл AOF, чтобы отредактировать его, добавить или удалить некоторые записи и, наконец, выполнить операцию восстановления, когда вам это нужно.
Сравнение недостатков метода RDB и метода AOF
Недостатки подхода RDB
-
Если вы хотите, чтобы в случае неожиданного прекращения работы Redis (например, при отключении электроэнергии) потери данных были минимальными, тогда RDB не для вас.
save
Временные точки (например, каждые 5 минут и 100 операций записи в набор данных), для Redis требуется большая рабочая нагрузка, чтобы полностью сохранить весь набор данных, обычно вы делаете это каждые 5 минут или чаще. , вы можете потерять несколько минут данных. -
RDB необходимо часто разветвлять подпроцессы, чтобы сохранить набор данных на жесткий диск.Когда набор данных относительно велик, процесс разветвления занимает очень много времени, что может привести к тому, что Redis не сможет отвечать на запросы клиентов в течение нескольких миллисекунд. Если набор данных огромен, а производительность процессора не очень хорошая, эта ситуация будет длиться 1 секунду, AOF также нуждается в форке, но вы можете настроить частоту перезаписи файла журнала, чтобы улучшить долговечность набора данных.
Недостатки метода АОФ
-
Для одного и того же набора данных размер файлов AOF обычно больше, чем размер файлов RDB.
-
В зависимости от используемой стратегии fsync AOF может работать медленнее, чем RDB. В целом производительность fsync в секунду по-прежнему очень высока, и отключение fsync может сделать AOF таким же быстрым, как RDB, даже при большой нагрузке. Однако при работе с огромными нагрузками записи RDB может обеспечить более гарантированную максимальную задержку (
latency
).
Сводка сравнения недостатков
Из-за редкого резервного копирования RDB данные могут быть потеряны в течение короткого периода времени при ответе на данные, а когда набор данных относительно велик, это может повлиять на запросы на миллисекундном уровне.
Упоминания файлов AOF относительно велики, и из-за высокой частоты сохранения общая скорость будет ниже, чем у RDB, но производительность по-прежнему высока.
Принцип работы
Перезапись AOF и создание моментальных снимков RDB разумно используют механизм копирования при записи:- Redis выполняет fork() и теперь имеет как родительский, так и дочерний процессы.
- Дочерний процесс начинает записывать содержимое нового файла AOF во временный файл.
- Для всех вновь выполняемых команд записи родительский процесс добавляет эти изменения в конец существующего файла AOF, накапливая их в кеше памяти, так что даже если происходит отключение в середине перезаписи, существующий файл AOF остается в безопасности.
- Когда дочерний процесс завершает работу по перезаписи, он отправляет сигнал родительскому процессу.После того, как родительский процесс получает сигнал, он добавляет все данные из кэша памяти в конец нового AOF-файла.
- Теперь Redis атомарно заменяет старый файл новым, после чего все команды добавляются непосредственно в конец нового файла AOF.
Применение на практике, реализация RDB и AOF
Включение и настройка сохраняемости RDB
Метод сохраняемости Redis по умолчанию — RDB, и он включен по умолчанию. Существует два способа сохранения RDB: активное сохранение и пассивное сохранение. Активное сохранение можно ввести в redis-clisave
Вот и все, пассивное сохранение должно соответствовать условиям срабатывания, заданным в файле конфигурации.В настоящее время официальные условия срабатывания по умолчанию можно найти вredis.conf
видел в:
save 900 1
save 300 10
save 60 10000
Его значение таково:
服务器在900秒之内,对数据库进行了至少1次修改
服务器在300秒之内,对数据库进行了至少10次修改。
服务器在60秒之内,对数据库进行了至少10000次修改。
После выполнения условий срабатывания данные будут сохранены в виде моментального снимка, поэтому целостность данных RDB не сравнима с целостностью AOF.
После срабатывания условия сохранения файл с именемdump.rdb
файл, и когда Redis запустится в следующий раз, Redis прочитает файлы в этом каталоге.dump.rdb
файл и восстановить данные в нем в Redis.
Где этот каталог?
Мы можем вводить команды в клиентеconfig get dir
Проверять:
gannicus@$ src/redis-cli
127.0.0.1:6379> config get dir
1) "dir"
2) "/home/gannicus/Documents/redis-5.0.0"
127.0.0.1:6379>
вернуть результат"/home/gannicus/Documents/redis-5.0.0"
хранитьdump.rdb
каталог.
Примечания к выпуску Redis
Перед тестированием сформулируйте предпосылку.redis
Это сжатый пакет, загруженный непосредственно с официального сайта и полученный после распаковки.redis-x.x.x
папка, как у меняredis-5.0.0
, затем перейдите в папку, вredis-5.0.0
Используйте корневой каталог проектаmake
команда для установки.
RDB пассивно запускает тест сохранения
Только что упомянул, что он делится на активное сохранение и пассивное срабатывание, теперь давайте проверим пассивное срабатывание. начать первымredis-server
, а затем откройте клиентredis-cli
, сначала добавьте несколько записей:
127.0.0.1:6379> set lca 1
OK
127.0.0.1:6379> set lcb 1
OK
127.0.0.1:6379> set lcc 1
OK
127.0.0.1:6379> set lcd 1
OK
127.0.0.1:6379> set lce 1
OK
127.0.0.1:6379> set lcf 1
OK
127.0.0.1:6379> set lcg 1
OK
127.0.0.1:6379> set lch 1
OK
127.0.0.1:6379> set lci 1
OK
127.0.0.1:6379> set lcj 1
OK
127.0.0.1:6379> set lck 1
OK
127.0.0.1:6379> set lcl 1
OK
127.0.0.1:6379> set lcm 1
OK
Как видите, всего добавлено 13 записей:
127.0.0.1:6379> keys *
1) "lca"
2) "lcd"
3) "lcg"
4) "lce"
5) "lcb"
6) "lcm"
7) "lcf"
8) "lci"
9) "lcl"
10) "lcc"
11) "lck"
12) "lcj"
13) "lch"
127.0.0.1:6379>
а потом нашелredis-server
В окне журнала терминала появляется следующая подсказка:
21971:M 21 Oct 2018 16:52:44.062 * 10 changes in 300 seconds. Saving...
21971:M 21 Oct 2018 16:52:44.063 * Background saving started by pid 22552
22552:C 21 Oct 2018 16:52:44.066 * DB saved on disk
21971:M 21 Oct 2018 16:52:44.165 * Background saving terminated with success
Вы можете примерно понять это содержимое из подсказки на английском языке.Он обнаруживает, что 10 записей были изменены в течение 300 секунд.Мы только что добавили 13 записей данных, чтобы удовлетворитьredis.conf
Условия для сохранения данных RDB в , поэтому операция сохранения данных выполняется здесь, и процесс 22552 открывается для выполнения операции сохранения, и, наконец, сохранение проходит успешно.
и смотри в каталоге что естьdump.rdb
генерация файлов.
Теперь убейте процесс Redis, какие данные будут сохранены?
по командеkill -9 pid
(pid — это номер процесса) Смоделируйте нештатное завершение работы Redis, а затем снова запустите Redis. Посмотрим, будут ли сохранены только 10 записей или все 13 записей?
127.0.0.1:6379> keys *
1) "lcb"
2) "lcj"
3) "lcd"
4) "lch"
5) "lci"
6) "lcc"
7) "lcf"
8) "lce"
9) "lca"
10) "lcg"
127.0.0.1:6379>
Проверьте записи после перезапуска и обнаружите, что будут сохранены только 10 записей из 13, что также подтверждает, что целостность данных в режиме RDB ненадежна, если только момент отключения не соответствует условиям запуска.
закрыть РБД
Как только что упоминалось, он включен по умолчанию, если он вам не нужен, вы можете закомментировать эти 3 конфигурации в файле конфигурации и добавить новыйsave ""
Просто:
save ""
# save 900 1
# save 300 10
# save 60 10000
После сохранения конфигурационного файла нужно перезапустить сервис Redis, чтобы он вступил в силу, а затем продолжить добавлять более десятка записей:
127.0.0.1:6379> keys *
1) "lcb"
...
23) "lca"
24) "lcg"
127.0.0.1:6379>
На основе предыдущих 10 я добавил 14 записей, в этот раз тоже черезkill
Чтобы имитировать аварийное завершение работы Redis, снова запустите службу, чтобы проверить, сохраняются ли данные:
127.0.0.1:6379> keys *
1) "lcb"
2) "lcj"
3) "lcd"
4) "lch"
5) "lci"
6) "lcc"
7) "lcf"
8) "lce"
9) "lca"
10) "lcg"
127.0.0.1:6379>
Выяснилось, что добавленные позже 14 записей не сохранились, а при восстановлении данных были восстановлены только предыдущие 10 записей. И наблюдая за журналом окна сервера Redis, нет запроса на запуск сохранения, как раньше, что доказывает, что режим RDB был закрыт.
RDB активно сохраняет тесты
Пассивные триггеры закрываются через конфигурационный файл, так что активное отключение по-прежнему будет действовать?
На клиенте Redis (redis-cli) черезdel
команда для удаления нескольких записей, затем введитеsave
Команда выполняет операцию сохранения:
127.0.0.1:6379> keys *
1) "lcc"
2) "lch"
3) "lcb"
4) "lci"
5) "lce"
6) "lcj"
7) "lcg"
8) "lca"
9) "lcd"
10) "lcf"
127.0.0.1:6379> del lca lcb lcc
(integer) 3
127.0.0.1:6379> save
OK
127.0.0.1:6379>
можно увидетьredis-server
В журнале появились новые подсказки:22598:M 21 Oct 2018 17:22:31.365 * DB saved on disk
, что говорит нам о том, что данные были сохранены.
Затем продолжайте имитировать аварийное завершение работы, а затем откройте службу, чтобы убедиться, что эти операции действительно сохраняются:
127.0.0.1:6379> keys *
1) "lci"
2) "lcj"
3) "lcd"
4) "lcg"
5) "lcf"
6) "lce"
7) "lch"
127.0.0.1:6379>
Разумеется, эти операции удаления были сохранены, и трех записей больше нет в восстановленных данных, что доказывает, что файл конфигурации не влияет на активное завершение работы.
Кромеsave
Есть ли другой способ сохранить его?
сохранить и сохранить bgsave
Да, Redis предоставляетsave
иbgsave
Это два разных метода сохранения, и оба метода будут вызываться при выполнении.rdbSave
функции, но называются они по-разному:
-
save
позвонить напрямуюrdbSave
метод, который блокирует основной процесс Redis до завершения сохранения. Пока основной процесс заблокирован, сервер не может обрабатывать запросы от клиентов. -
bgsave
Затем создайте дочерний процесс, и дочерний процесс отвечает за вызовrdbSave
, и отправить сигнал основному процессу после завершения сохранения, уведомляя о том, что сохранение завершено. так какrdbSave
вызывается в дочернем процессе, поэтому сервер Redisbgsave
Запросы клиентов все еще могут обрабатываться во время выполнения.
save
синхронная операция,bgsave
является асинхронной операцией.
bgsave
как использовать команду иsave
Использование команды такое же:
127.0.0.1:6379> keys *
1) "lci"
2) "lcj"
3) "lcd"
4) "lcg"
5) "lcf"
6) "lce"
7) "lch"
127.0.0.1:6379> del lci lcj
(integer) 2
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> keys *
1) "lcd"
2) "lcg"
3) "lcf"
4) "lce"
5) "lch"
127.0.0.1:6379>
выключение сохранить
По факту,shutdown
Команды тоже могут сохранять данные, что неудивительно. Он сохраняет данные перед выключением, неудивительно?
127.0.0.1:6379> set app 1
OK
127.0.0.1:6379> set apps 1
OK
127.0.0.1:6379> keys *
1) "apps"
2) "lcd"
3) "lcg"
4) "lcf"
5) "app"
6) "lce"
7) "lch"
127.0.0.1:6379> shutdown
not connected> quit
gannicus@$
Затем служба Redis закрывается. Нам нужно перезапустить службу Redis и перейти к клиенту, чтобы увидеть, подействует ли это:
gannicus@$ src/redis-cli
127.0.0.1:6379> keys *
1) "lce"
2) "lcf"
3) "lcd"
4) "lch"
5) "lcg"
Не подействовало, укус не раздражает? Почему это? Минминзакрытие официальной документацииЯ сказал, что сохраню его, прежде чем уйти, ты солгал~
Обратите внимание, что в документе есть предложение
Внезапно сообразил, оказалось в том случае, если настойчивость включена, черезshutdown
Команда будет закрыта, чтобы никакие данные не были потеряны, затем перейдите в файл конфигурации и добавьте те несколькоsave
Откройте элемент конфигурации:
# save ""
save 900 1
save 300 10
save 60 10000
Затем запустите службу Redis и повторите попытку (процесс: добавить -> выключение -> перезапустить службу -> просмотреть):
127.0.0.1:6379> set app 1
OK
127.0.0.1:6379> set apps 1
OK
127.0.0.1:6379> shutdown
not connected> quit
gannicus@$ src/redis-cli
127.0.0.1:6379> keys *
1) "lce"
2) "lch"
3) "app"
4) "lcf"
5) "apps"
6) "lcd"
7) "lcg"
127.0.0.1:6379>
Наконец-то сейчас разобрался.
Включение и настройка сохраняемости AOF
Включить АОФ
AOF не включен по умолчанию, если вы хотите включить его, вам нужно перейти кredis.conf
Откройте в файле конфигурации, откройтеredis.conf
:
$ vim redis.conf
затем найдите в файлеappendonly
и воляno
изменить наyes
:
appendonly yes
То есть, сохранение метода AOF включено.
Установить метод синхронизации
AOF также поддерживает несколько методов синхронизации, а именно:
appendfsync always # 每次有数据修改发生时都会写入AOF文件(安全但是费时)。
appendfsync everysec # 每秒钟同步一次,该策略为AOF的缺省策略。
appendfsync no # 从不同步。高效但是数据不会被持久化。
Конфигурация по умолчаниюeverysec
, вы можете настроить его в соответствии с вашими потребностями, здесь я изменю конфигурацию наalways
:
appendfsync always
# appendfsync everysec
# appendfsync no
Настройте имя файла записи AOF
Redis настроен с именем файла по умолчанию, которое отображается в конфигурации как:
appendfilename "appendonly.aof"
Вы можете оставить его с именем по умолчанию или указать другое имя файла, например:
appendfilename "RNGLetme.aof"
будетappendonly
,appendfsync
иappendfilename
Установите и сохраните. Перезапустите службу Redis:
$./redis-server
по командеls
Глядя на локальный файл, вы можете увидеть, что новый файл с именемRNGLetme.aof
файл, вы можете использовать:
$cat RNGLetme.aof
Чтобы просмотреть содержимое внутри, оно пустое, поскольку данные не были изменены.
Затем откройте клиент Redis:
$./redis-cli
И добавьте несколько записей данных:
127.0.0.1:6379> set rng lpl
OK
127.0.0.1:6379> set ig lpl
OK
127.0.0.1:6379> set edg lpl
OK
127.0.0.1:6379> keys *
1) "edg"
2) "rng"
3) "ig"
127.0.0.1:6379>
Как видите, он был успешно добавленrng
,edg
,ig
эти три записи, затем откройтеRNGLetme.aof
файл, посмотрите записи внутри:
*2
$6
SELECT
$1
0
*3
$3
set
$3
rng
$3
lpl
*3
$3
set
$2
ig
$3
lpl
*3
$3
set
$3
edg
$3
lpl
Каждое добавление данных записывается.
Если это операция удаления, будет ли она также записана?
127.0.0.1:6379> del edg
(integer) 1
127.0.0.1:6379> keys *
1) "rng"
2) "ig"
127.0.0.1:6379>
После выполнения операции удаления взгляните еще разRNGLetme.aof
Записи в файле:
*2
$6
SELECT
$1
0
*3
$3
set
$3
rng
$3
lpl
*3
$3
set
$2
ig
$3
lpl
*3
$3
set
$3
edg
$3
lpl
*2
$3
del
$3
edg
По сравнению с предыдущим рекордом, новыйdel edg
записи операций. Это подтверждает предыдущее описание AOF: изменения данных фиксируются в журнале.
Тест восстановления AOF
Следующее также черезkill
Команда имитирует аварийное завершение работы Redis:
gannicus@$ kill -9 22645
Затем перезапустите службу Redis:
$ src/redis-server redis.conf
Затем просмотрите клиент, чтобы увидеть, есть ли данные:
$ src/redis-cli
127.0.0.1:6379> keys *
1) "ig"
2) "rng"
можно увидеть,rng
иig
все еще там, что означает, что настойчивость в действии.
Как переключиться из режима RDB в режим AOF
В Redis 2.2 или выше можно переключиться с RDB на AOF без перезапуска:
Создайте резервную копию последнего файла dump.rdb и поместите резервную копию в безопасное место. Выполните следующие две команды:
redis-cli config set appendonly yes
redis-cli config set save “”
Убедитесь, что команды записи правильно добавлены в конец файла AOF. Первая выполненная команда включает функцию AOF: Redis будет блокироваться до тех пор, пока не будет создан начальный файл AOF, после чего Redis продолжит обработку командных запросов и начнет добавлять команды записи в конец файла AOF.
Вторая выполняемая команда отключает функциональность RDB. Этот шаг является необязательным, и вы можете использовать функции сохранения RDB и AOF одновременно, если хотите.
важный: не забудьredis.conf
Включите функцию AOF в! В противном случае после перезагрузки сервера предыдущий проходCONFIG SET
Заданная командой конфигурация будет забыта, и программа запустит сервер с исходной конфигурацией.
Предпочитаете RDB или AOF?
Проанализировав и сравнив два метода и проведя тесты, я обнаружил, что это два разных стиля методов сохраняемости, так что же мне выбрать?
- Для средних и крупных приложений корпоративного уровня, если вы не хотите жертвовать целостностью данных, но хотите поддерживать высокую эффективность, вам следует использовать как RDB, так и AOF;
- Если вы не планируете тратить энергию на это место и вам нужно только обеспечить целостность данных, то отдайте приоритет использованию метода AOF;
- Метод RDB очень подходит для крупномасштабного восстановления данных.Если бизнес не требует высокой целостности и непротиворечивости данных, RDB является хорошим выбором.
Рекомендации по резервному копированию данных Redis
Убедитесь, что у вас есть полная резервная копия ваших данных. Такие проблемы, как сбои дисков, сбои узлов и т. д., могут привести к исчезновению ваших данных. Не делать резервные копии очень опасно.
Redis очень удобен для резервного копирования данных, потому что вы можете скопировать файл RDB во время работы сервера: после создания файла RDB ничего не изменяется. Когда сервер хочет создать новый файл RDB, он сначала сохраняет содержимое файла во временном файле, а когда временный файл записывается, программа используетrename(2)
Атомарно замените исходный файл RDB временным файлом.
Это означает, что копировать файлы RDB абсолютно безопасно, когда это возможно.
-
Создайте задание cron, которое создает резервную копию одного файла RDB в одну папку каждый час и одного файла RDB каждый день в другую папку.
-
Убедитесь, что резервные копии моментальных снимков имеют соответствующую информацию о дате и времени, каждый раз, когда выполняется сценарий периодической задачи, используйте
find
Команда для удаления моментальных снимков с истекшим сроком действия: например, вы можете сохранять ежечасные снимки за последние 48 часов и ежедневные снимки за последний месяц или два. -
Не реже одного раза в день создавайте резервную копию RDB за пределами вашего центра обработки данных или, по крайней мере, за пределами физической машины, на которой вы запускаете сервер Redis.
Сохранение пароля Redis
В Redis данные должны быть постоянными, и пароли также должны быть постоянными. На клиенте через команду:
config set requirepass zxc9527
Вы можете установить значение для Redis какzxc9527
, но когда Redis будет закрыт и перезапущен, функция проверки разрешений завершится ошибкой, и пароль не потребуется. Поэтому пароль тоже должен быть вredis.conf
средняя стойкость. Открытымredis.conf
оказатьсяrequirepass
элемент конфигурации, раскомментируйте его и установите пароль позже:
requirepass zxc9527
После сохранения перезапустите службу Redis, и сохранение пароля вступит в силу.