Да, вы можете, но с большим предостережением.
Любой подчиненный экземпляр может быть мастером одного или нескольких других экземпляров. Таким образом, вы можете представить себе цепочку slave slave и создать иерархическую систему репликации.
Теперь я понимаю, что вам не нужен ваш подчиненный, чтобы подать другой экземпляр Redis, но просто разрешите приложению выполнять операции чтения/записи в другой базе данных подчиненного экземпляра.
Чтобы разрешить это, необходимо установить значение рабского только для чтения параметра «нет» в конфигурации подчиненного:
# You can configure a slave instance to accept writes or not. Writing against
# a slave instance may be useful to store some ephemeral data (because data
# written on a slave will be easily deleted after resync with the master) but
# may also cause problems if clients are writing to it because of a
# misconfiguration.
#
# Since Redis 2.6 by default slaves are read-only.
#
# Note: read only slaves are not designed to be exposed to untrusted clients
# on the internet. It's just a protection layer against misuse of the instance.
# Still a read only slave exports by default all the administrative commands
# such as CONFIG, DEBUG, and so forth. To a limited extend you can improve
# security of read only slaves using 'rename-command' to shadow all the
# administrative/dangerous commands.
slave-read-only no
Теперь все операции записи вы будете работать на этом примере будет ephemeral. Если связь потеряна между ведущим и ведомым, ведомое устройство полностью синхронизируется с ведущим устройством. Все данные, которые вы установили на ведомом , будут потеряны. Если вы остановите и перезапустите ведомый, вы также потеряете все эфемерные данные.
Может потребоваться или не соответствовать вашим потребностям.
Невозможно параметризовать синхронизацию (или параметры сохранения) на уровне базы данных. Вы не можете сказать Redis синхронизировать данную базу данных, а не другую. Конфигурация всегда применяется на уровне экземпляра.