Перемещение данных Redis с помощью репликации по типу master-slave в Ubuntu 14.04

Ubuntu | Amber | Комментировать запись

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

В некоторых ситуациях (например, при переходе на более мощный сервер) возникает необходимость перенести данные с одного сервера на другой.

В целом, можно просто скопировать файлы базы данных с текущего сервера на новый. Однако более надёжный метод перемещения базы данных Redis основывается на репликации по типу master-slave. Такое перемещение выполняется гораздо быстрее, чем копирование файлов, и происходит почти без простоев.

Данное руководство научит перемещать данные Redis с сервера Ubuntu 14.04 на подобный сервер при помощи репликации master-slave.

Требования

Для выполнения руководства необходимо подготовить два сервера Ubuntu 14.04: первый будет сервером master (на нём будут храниться данные, которые нужно переместить), а второй – сервером slave.

Требования к серверу master:

• Не-root пользователь с доступом к sudo (о настройке такого пользователя можно прочитать в этом руководстве).
• Настроенный брандмауэр IPTables.
• Предварительно установленный Redis; сервер нужно настроить как master (инструкции – в разделе 1 и 2 этого руководства).
• Данные, которые нужно переместить.

Требования к серверу slave:

• Не-root пользователь с доступом к sudo.
• Настроенный брандмауэр IPTables.
• Предварительно установленный Redis; сервер нужно настроить как master (инструкции – в разделе 1-3 этого руководства).

1: Настройка брандмауэра сервера master

Итак, на данный момент у вас есть два независимых сервера – master и slave. Эти серверы не могут взаимодействовать из-за брандмауэра, который блокирует их соединение.

Чтобы исправить это, добавьте исключение в правила брандмауэра на сервере master. Нужно разблокировать трафик на порт 6379. Откройте конфигурационный файл IPTables для IPv4:

sudo nano /etc/iptables/rules.v4

После правила для SSH поместите правило, разрешающее трафик на порт Redis только от IP-адреса сервера slave. В правиле замените your_slave_ip_address IP-адресом сервера slave.

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

Такое правило обеспечивает более надёжную защиту сервера.

Чтобы обновить настройки, перезапустите IPTables:

sudo service iptables-persistent restart

Теперь система репликации и брандмауэр сервера master пропускают трафик Redis. Убедитесь, что серверы master и slave могут взаимодействовать (чтобы узнать, как можно проверить взаимодействие, читайте раздел 4 этого руководства).

2: Обмен данными

Если взаимодействие между серверами успешно установлено, импорт данных с сервера master на slave начнётся автоматически. Убедитесь, что обмен данными между серверами состоялся. Существует несколько способов сделать это.

Каталог данных Redis

Первый способ убедиться в том, что импорт данных прошел успешно – проверить каталог данных Redis. На серверах master и slave должны храниться одинаковые данные. Запустите на сервере slave:

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. На сервере slave введите:

redis-cli

Пройдите авторизацию и выполните команду info:

auth insert-redis-password-here
info

В полученном результате количество ключей в # Keyspace на обоих серверах должно быть одинаковым. Ниже приведён вывод на сервере slave (в данном случае результаты совпали)

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

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

Ещё один способ убедиться в том, что импорт данных между серверами прошёл успешно – использовать команду scan. Вывод этой команды на серверах не должен совпадать; команда позволит узнать, хранятся ли на сервере slave необходимые данные.

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

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: Изменение статуса сервера slave

Примечание: Дополнительные инструкции можно найти в разделе «Настройка аварийного переключения» этого руководства.

Убедившись, что все необходимые данные были перемещены на сервер slave, нужно повысить текущий slave до статуса master.

Откройте командную строку Redis:

redis-cli

Затем выполните команду slaveof no one, чтобы перевести сервер в статус master.

auth your_redis_password
slaveof no one

Команда должна вернуть:

OK

Чтобы убедиться в том, что статус изменился, введите:

info

В полученном выводе найдите раздел Replication; строка role:master сообщает, что статус сервера изменился:

# Replication
role:master
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

Также в логе предыдущего сервера master должна быть следующая запись:

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

А в логе нового сервера master будет следующее:

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')

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

Заключение

Как видите, перемещать данные при помощи репликации очень легко. Главной ошибкой при этом, как правило, является неправильно настроенный брандмауэр.