TOC

Как перенести данные Redis с репликацией Master-Slave в Ubuntu 14.04

Вступление

Redis - это оперативная память, NoSQL, кэш-память и ключ-значение, которые также можно сохранить на диске. Его популярность растет, и он используется в качестве хранилища данных как в больших, так и в маленьких проектах. По ряду причин, например, при переходе на более мощный сервер, иногда возникает необходимость перенести эти данные с одного сервера на другой.

Хотя можно просто скопировать файлы базы данных с текущего сервера на новый, рекомендуемый метод переноса базы данных Redis заключается в использовании настройки репликации в режиме «ведущий-ведомый». Такая настройка намного быстрее, чем копирование файлов, и требует очень мало времени простоя или совсем не требует времени.

В этой статье будет показано, как перенести данные Redis с сервера Ubuntu 14.04 на аналогичный сервер с использованием репликации «главный-подчиненный». Это включает в себя настройку нового сервера Redis, настройку его в качестве ведомого текущего сервера (т.е. мастер), затем продвижение рабов к мастеру после завершения миграции.

Предпосылки

Чтобы следовать этой статье, вам понадобится один главный сервер Redis с данными, которые вы хотите экспортировать или перенести, и второй новый сервер Redis, который будет подчиненным.

В частности, это предварительные условия для мастера Redis.

И это обязательные условия для рабов Redis.

Обязательно следуйте разделу конфигурации сервера имен в руководстве по IPTables на обоих серверах; без него + apt + не сработает.

Шаг 1 - Обновление Redis Master Firewall

После установки и настройки подчиненного устройства Redis у вас есть два независимых сервера, которые не взаимодействуют из-за правил брандмауэра. На этом этапе мы исправим это

Исправление включает в себя добавление исключения к правилам TCP на главном сервере, чтобы разрешить трафик Redis через порт 6379. Итак, на главном сервере откройте файл конфигурации IPTables для правил IPv4.

sudo nano /etc/iptables/rules.v4

Прямо под правилом, разрешающим трафик SSH, добавьте правило для Redis, разрешающее трафик через порт Redis only с IP-адреса ведомого. Обязательно обновите ++ до IP-адреса подчиненного сервера.

/etc/iptables/rules.v4

. . .
# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT

. . .

Это очень ограничительно и более безопасно. В противном случае сервер будет принимать трафик с любого хоста на порте Redis.

Перезапустите IPTables, чтобы применить новое правило.

sudo service iptables-persistent restart

Теперь, когда система репликации запущена и брандмауэр на главном сервере настроен на пропуск трафика Redis, мы можем убедиться, что оба сервера могут обмениваться данными. Это можно сделать с помощью инструкций, приведенных в шаге 4 из this кластера Redis. .

Шаг 2 - Проверка импорта данных

Если оба сервера установили контакт, импорт данных с сервера на ведомое устройство должен начаться автоматически. Теперь вам нужно только убедиться, что оно выполнено и успешно выполнено. Есть несколько способов проверить это.

Redis Data Directory

Один из способов проверки успешного импорта данных - поиск в каталоге данных Redis. Те же файлы, которые находятся на ведущем устройстве, теперь должны быть на ведомом устройстве. Если вы делаете длинный список файлов в каталоге данных Redis подчиненного сервера с помощью этой команды:

ls -lh /var/lib/redis

Вы должны получить вывод такого рода:

Выход

total 32M
-rw-r----- 1 redis redis 19M Oct  6 22:53 appendonly.aof
-rw-rw---- 1 redis redis 13M Oct  6 22:53 dump.rdb

Командная строка Redis

Еще один метод проверки импорта данных из командной строки Redis. Введите командную строку на подчиненном сервере.

redis-cli

Затем выполните аутентификацию и введите команду + info +

auth

info

В выводе количество ключей в * # Keyspace * должно быть одинаковым на обоих серверах. Вывод ниже был взят с подчиненного сервера, который был точно таким же, как вывод на главном сервере.

Выход

# Keyspace
db0:keys=26378,expires=0,avg_ttl=0

Сканирование ключей

Еще один метод проверки того, что ведомое устройство теперь имеет те же данные, что и на главном устройстве, заключается в использовании команды + scan + из командной строки Redis. Хотя выходные данные этой команды не всегда будут одинаковыми на обоих серверах, при выдаче на ведомое устройство оно по крайней мере позволит вам подтвердить, что ведомое устройство имеет данные, которые вы ожидаете найти на нем.

Пример вывода с тестового сервера, использованного для этой статьи, показан ниже. Обратите внимание, что аргументом команды + scan + является любое число и он действует как курсор:

scan 0

Вывод должен быть похож на это:

Выход

1) "17408"
2)  1) "uid:5358:ip"
   2) "nodebbpostsearch:object:422"
   3) "uid:4163:ip"
   4) "user:15682"
   5) "user:1635"
   6) "nodebbpostsearch:word:HRT"
   7) "uid:6970:ip"
   8) "user:15641"
   9) "tid:10:posts"
  10) "nodebbpostsearch:word:AKL"
  11) "user:4648"
127.0.0.1:6379>

Шаг 3 - Продвижение Раба к Мастеру

После того, как вы подтвердите, что ведомое устройство имеет все данные, вы можете повысить их до мастер-класса. Это также описано в https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04#step-5-%E2%80%94- switch-to-slave [шаг 5 учебника по кластеру Redis], но для простоты здесь также есть инструкции.

Сначала введите командную строку Redis на ведомом устройстве.

redis-cli

После проверки подлинности выполните команду + slaveof no one +, чтобы повысить ее до уровня мастера.

auth
slaveof no one

Вы должны получить этот вывод:

Выход

OK

Затем используйте команду + info + для подтверждения.

info

Соответствующий вывод в разделе * Replication * должен выглядеть следующим образом. В частности, строка * role: master * показывает, что ведомое устройство теперь является ведущим.

Выход

# Replication

connected_slaves:0
master_repl_offset:11705
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Впоследствии, одна запись в файле журнала бывшего мастера также должна подтвердить это.

/var/log/redis/redis-server.log

14613:M 07 Oct 14:03:44.159 # Connection with slave 192.168.1.8:6379 lost.

А на новом хозяине (ранее раб) вы должны увидеть:

/var/log/redis/redis-server.log

14573:M 07 Oct 14:03:44.150 # Connection with master lost.
14573:M 07 Oct 14:03:44.150 * Caching the disconnected master state.
14573:M 07 Oct 14:03:44.151 * Discarding previously cached master state.
14573:M 07 Oct 14:03:44.151 * MASTER MODE enabled (user request from 'id=4 addr=127.0.0.1:52055 fd=6 name= age=2225 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

Теперь вы можете подключить приложения к базе данных и удалить или уничтожить исходный мастер.

Заключение

Если все сделано правильно, миграция данных Redis таким способом является простой задачей. Основным источником ошибок обычно является забвение изменения брандмауэра главного сервера, чтобы разрешить трафик Redis.

Вы можете узнать, как сделать больше с Redis, просмотрев more учебники Redis.

Related