Skip to content

G
gitlab-ce
Commit a77d736d authored by Ian Baum's avatar Ian Baum
Browse files
Options

Change usage of Redis slave to replica 

* This was renamed in Redis 5.0, and will eventually be removed

https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5141
parent 9e05007c
Hide whitespace changes
Inline Side-by-side
Showing with 113 additions and 113 deletions
config/redis.cache.yml.example
View file @ a77d736d
......@@ -10,7 +10,7 @@ development:
# host: localhost
# port: 26380 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26380 # point to sentinel, not to redis port
test:
url: redis://localhost:6379/10
......@@ -31,8 +31,8 @@ production:
# url: redis://master:6380
# sentinels:
# -
# host: slave1
# host: replica1
# port: 26380 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26380 # point to sentinel, not to redis port
config/redis.queues.yml.example
View file @ a77d736d
......@@ -10,7 +10,7 @@ development:
# host: localhost
# port: 26381 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26381 # point to sentinel, not to redis port
test:
url: redis://localhost:6379/11
......@@ -31,8 +31,8 @@ production:
# url: redis://master:6381
# sentinels:
# -
# host: slave1
# host: replica1
# port: 26381 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26381 # point to sentinel, not to redis port
config/redis.shared_state.yml.example
View file @ a77d736d
......@@ -10,7 +10,7 @@ development:
# host: localhost
# port: 26382 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26382 # point to sentinel, not to redis port
test:
url: redis://localhost:6379/12
......@@ -31,8 +31,8 @@ production:
# url: redis://master:6382
# sentinels:
# -
# host: slave1
# host: replica1
# port: 26382 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26382 # point to sentinel, not to redis port
config/resque.yml.example
View file @ a77d736d
......@@ -8,7 +8,7 @@ development:
# host: localhost
# port: 26380 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26381 # point to sentinel, not to redis port
test:
url: redis://localhost:6379
......@@ -27,8 +27,8 @@ production:
# url: redis://master:6379
# sentinels:
# -
# host: slave1
# host: replica1
# port: 26379 # point to sentinel, not to redis port
# -
# host: slave2
# host: replica2
# port: 26379 # point to sentinel, not to redis port
doc/administration/high_availability/redis.md
View file @ a77d736d
......@@ -98,7 +98,7 @@ Starting with 8.14, Redis Sentinel is no longer experimental.
If you've used it with versions `< 8.14` before, please check the updated
documentation here.
High Availability with [Redis](https://redis.io/) is possible using a **Master** x **Slave**
High Availability with [Redis](https://redis.io/) is possible using a **Master** x **Replica**
topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
start the failover procedure.
......@@ -130,12 +130,12 @@ make sure you read this Overview section to better understand how the components
are tied together.
You need at least `3` independent machines: physical, or VMs running into
distinct physical machines. It is essential that all master and slaves Redis
distinct physical machines. It is essential that all master and replica Redis
instances run in different machines. If you fail to provision the machines in
that specific way, any issue with the shared environment can bring your entire
setup down.
It is OK to run a Sentinel alongside of a master or slave Redis instance.
It is OK to run a Sentinel alongside of a master or replica Redis instance.
There should be no more than one Sentinel on the same machine though.
You also need to take into consideration the underlying network topology,
......@@ -156,16 +156,16 @@ components below.
High Availability with Redis requires a few things:
- Multiple Redis instances
- Run Redis in a **Master** x **Slave** topology
- Run Redis in a **Master** x **Replica** topology
- Multiple Sentinel instances
- Application support and visibility to all Sentinel and Redis instances
Redis Sentinel can handle the most important tasks in an HA environment and that's
to help keep servers online with minimal to no downtime. Redis Sentinel:
- Monitors **Master** and **Slaves** instances to see if they are available
- Promotes a **Slave** to **Master** when the **Master** fails
- Demotes a **Master** to **Slave** when the failed **Master** comes back online
- Monitors **Master** and **Replicas** instances to see if they are available
- Promotes a **Replica** to **Master** when the **Master** fails
- Demotes a **Master** to **Replica** when the failed **Master** comes back online
(to prevent data-partitioning)
- Can be queried by the application to always connect to the current **Master**
server
......@@ -185,8 +185,8 @@ For a minimal setup, you will install the Omnibus GitLab package in `3`
**independent** machines, both with **Redis** and **Sentinel**:
- Redis Master + Sentinel
- Redis Slave + Sentinel
- Redis Slave + Sentinel
- Redis Replica + Sentinel
- Redis Replica + Sentinel
If you are not sure or don't understand why and where the amount of nodes come
from, read [Redis setup overview](#redis-setup-overview) and
......@@ -197,14 +197,14 @@ the Omnibus GitLab package in `5` **independent** machines, both with
**Redis** and **Sentinel**:
- Redis Master + Sentinel
- Redis Slave + Sentinel
- Redis Slave + Sentinel
- Redis Slave + Sentinel
- Redis Slave + Sentinel
- Redis Replica + Sentinel
- Redis Replica + Sentinel
- Redis Replica + Sentinel
- Redis Replica + Sentinel
### Redis setup overview
You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they
You must have at least `3` Redis servers: `1` Master, `2` Replicas, and they
need to each be on independent machines (see explanation above).
You can have additional Redis nodes, that will help survive a situation
......@@ -221,7 +221,7 @@ nodes to be provisioned. See [Sentinel setup overview](#sentinel-setup-overview)
documentation for more information.
All Redis nodes should be configured the same way and with similar server specs, as
in a failover situation, any **Slave** can be promoted as the new **Master** by
in a failover situation, any **Replica** can be promoted as the new **Master** by
the Sentinel servers.
The replication requires authentication, so you need to define a password to
......@@ -241,9 +241,9 @@ need to be available and reachable, so that they can elect the Sentinel **leader
who will take all the decisions to restore the service availability by:
- Promoting a new **Master**
- Reconfiguring the other **Slaves** and make them point to the new **Master**
- Reconfiguring the other **Replicas** and make them point to the new **Master**
- Announce the new **Master** to every other Sentinel peer
- Reconfigure the old **Master** and demote to **Slave** when it comes back online
- Reconfigure the old **Master** and demote to **Replica** when it comes back online
You must have at least `3` Redis Sentinel servers, and they need to
be each in an independent machine (that are believed to fail independently),
......@@ -280,18 +280,18 @@ the official documentation:
already tried against the same master by a given Sentinel, is two
times the failover timeout.
- The time needed for a slave replicating to a wrong master according
- The time needed for a replica replicating to a wrong master according
to a Sentinel current configuration, to be forced to replicate
with the right master, is exactly the failover timeout (counting since
the moment a Sentinel detected the misconfiguration).
- The time needed to cancel a failover that is already in progress but
did not produced any configuration change (SLAVEOF NO ONE yet not
acknowledged by the promoted slave).
did not produced any configuration change (REPLICAOF NO ONE yet not
acknowledged by the promoted replica).
- The maximum time a failover in progress waits for all the slaves to be
reconfigured as slaves of the new master. However even after this time
the slaves will be reconfigured by the Sentinels anyway, but not with
- The maximum time a failover in progress waits for all the replicas to be
reconfigured as replicas of the new master. However even after this time
the replicas will be reconfigured by the Sentinels anyway, but not with
the exact parallel-syncs progression as specified.
### Available configuration setups
......@@ -306,12 +306,12 @@ Pick the one that suits your needs.
documentation.
- [Omnibus GitLab **Community Edition** (CE) package](https://about.gitlab.com/install/?version=ce): Redis is bundled, so you
can use the package with only the Redis service enabled as described in steps
1 and 2 of this document (works for both master and slave setups). To install
1 and 2 of this document (works for both master and replica setups). To install
and configure Sentinel, jump directly to the Sentinel section in the
[Redis HA installation from source](redis_source.md#step-3-configuring-the-redis-sentinel-instances) documentation.
- [Omnibus GitLab **Enterprise Edition** (EE) package](https://about.gitlab.com/install/?version=ee): Both Redis and Sentinel
are bundled in the package, so you can use the EE package to set up the whole
Redis HA infrastructure (master, slave and Sentinel) which is described in
Redis HA infrastructure (master, replica and Sentinel) which is described in
this document.
- If you have installed GitLab using the Omnibus GitLab packages (CE or EE),
but you want to use your own external Redis server, follow steps 1-3 in the
......@@ -328,9 +328,9 @@ This is the section where we install and set up the new Redis instances.
> - We assume that you have installed GitLab and all HA components from scratch. If you
> already have it installed and running, read how to
> [switch from a single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha).
> - Redis nodes (both master and slaves) will need the same password defined in
> - Redis nodes (both master and replica) will need the same password defined in
> `redis['password']`. At any time during a failover the Sentinels can
> reconfigure a node and change its status from master to slave and vice versa.
> reconfigure a node and change its status from master to replica and vice versa.
### Prerequisites
......@@ -392,9 +392,9 @@ The prerequisites for a HA Redis setup are the following:
> `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about high
> availability roles at <https://docs.gitlab.com/omnibus/roles/>.
### Step 2. Configuring the slave Redis instances
### Step 2. Configuring the replica Redis instances
1. SSH into the **slave** Redis server.
1. SSH into the **replica** Redis server.
1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
package you want using **steps 1 and 2** from the GitLab downloads page.
- Make sure you select the correct Omnibus package, with the same version
......@@ -404,8 +404,8 @@ The prerequisites for a HA Redis setup are the following:
1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
```ruby
# Specify server role as 'redis_slave_role'
roles ['redis_slave_role']
# Specify server role as 'redis_replica_role'
roles ['redis_replica_role']
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
......@@ -435,10 +435,10 @@ The prerequisites for a HA Redis setup are the following:
```
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other slave nodes.
1. Go through the steps again for all the other replica nodes.
> Note: You can specify multiple roles like sentinel and Redis as:
> `roles ['redis_sentinel_role', 'redis_slave_role']`. Read more about high
> `roles ['redis_sentinel_role', 'redis_replica_role']`. Read more about high
> availability roles at <https://docs.gitlab.com/omnibus/roles/>.
---
......@@ -542,18 +542,18 @@ multiple machines with the Sentinel daemon.
## already tried against the same master by a given Sentinel, is two
## times the failover timeout.
##
## - The time needed for a slave replicating to a wrong master according
## - The time needed for a replica replicating to a wrong master according
## to a Sentinel current configuration, to be forced to replicate
## with the right master, is exactly the failover timeout (counting since
## the moment a Sentinel detected the misconfiguration).
##
## - The time needed to cancel a failover that is already in progress but
## did not produced any configuration change (SLAVEOF NO ONE yet not
## acknowledged by the promoted slave).
## did not produced any configuration change (REPLICAOF NO ONE yet not
## acknowledged by the promoted replica).
##
## - The maximum time a failover in progress waits for all the slaves to be
## reconfigured as slaves of the new master. However even after this time
## the slaves will be reconfigured by the Sentinels anyway, but not with
## - The maximum time a failover in progress waits for all the replica to be
## reconfigured as replicas of the new master. However even after this time
## the replicas will be reconfigured by the Sentinels anyway, but not with
## the exact parallel-syncs progression as specified.
# sentinel['failover_timeout'] = 60000
```
......@@ -612,7 +612,7 @@ replicate from this machine first, before de-activating the Redis instance
inside it.
Your single-machine install will be the initial **Master**, and the `3` others
should be configured as **Slave** pointing to this machine.
should be configured as **Replica** pointing to this machine.
After replication catches up, you will need to stop services in the
single-machine install, to rotate the **Master** to one of the new nodes.
......@@ -627,7 +627,7 @@ redis['enable'] = false
If you fail to replicate first, you may loose data (unprocessed background jobs).
## Example of a minimal configuration with 1 master, 2 slaves and 3 Sentinels
## Example of a minimal configuration with 1 master, 2 replicas and 3 Sentinels
>**Note:**
Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For
......@@ -649,8 +649,8 @@ discussed in [Redis setup overview](#redis-setup-overview) and
Here is a list and description of each **machine** and the assigned **IP**:
- `10.0.0.1`: Redis Master + Sentinel 1
- `10.0.0.2`: Redis Slave 1 + Sentinel 2
- `10.0.0.3`: Redis Slave 2 + Sentinel 3
- `10.0.0.2`: Redis Replica 1 + Sentinel 2
- `10.0.0.3`: Redis Replica 2 + Sentinel 3
- `10.0.0.4`: GitLab application
Please note that after the initial configuration, if a failover is initiated
......@@ -684,12 +684,12 @@ sentinel['quorum'] = 2
[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
### Example configuration for Redis slave 1 and Sentinel 2
### Example configuration for Redis replica 1 and Sentinel 2
In `/etc/gitlab/gitlab.rb`:
```ruby
roles ['redis_sentinel_role', 'redis_slave_role']
roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.2'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
......@@ -706,12 +706,12 @@ sentinel['quorum'] = 2
[Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
### Example configuration for Redis slave 2 and Sentinel 3
### Example configuration for Redis replica 2 and Sentinel 3
In `/etc/gitlab/gitlab.rb`:
```ruby
roles ['redis_sentinel_role', 'redis_slave_role']
roles ['redis_sentinel_role', 'redis_replica_role']
redis['bind'] = '10.0.0.3'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
......@@ -847,11 +847,11 @@ mailroom['enable'] = false
-------
## Redis master/slave Role
## Redis master/replica Role
redis_master_role['enable'] = true # enable only one of them
redis_slave_role['enable'] = true # enable only one of them
redis_replica_role['enable'] = true # enable only one of them
# When Redis Master or Slave role are enabled, the following services are
# When Redis Master or Replica role are enabled, the following services are
# enabled/disabled. Note that if Redis and Sentinel roles are combined, both
# services will be enabled.
......@@ -863,7 +863,7 @@ postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false
# For Redis Slave role, also change this setting from default 'true' to 'false':
# For Redis Replica role, also change this setting from default 'true' to 'false':
redis['master'] = false
```
......@@ -894,13 +894,13 @@ You can check if everything is correct by connecting to each server using
```
When connected to a `master` Redis, you will see the number of connected
`slaves`, and a list of each with connection details:
`replicas`, and a list of each with connection details:
```plaintext
# Replication
role:master
connected_slaves:1
slave0:ip=10.133.5.21,port=6379,state=online,offset=208037514,lag=1
connected_replicas:1
replica0:ip=10.133.5.21,port=6379,state=online,offset=208037514,lag=1
master_repl_offset:208037658
repl_backlog_active:1
repl_backlog_size:1048576
......@@ -908,21 +908,21 @@ repl_backlog_first_byte_offset:206989083
repl_backlog_histlen:1048576
```
When it's a `slave`, you will see details of the master connection and if
When it's a `replica`, you will see details of the master connection and if
its `up` or `down`:
```plaintext
# Replication
role:slave
role:replica
master_host:10.133.1.58
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:208096498
slave_priority:100
slave_read_only:1
connected_slaves:0
replica_repl_offset:208096498
replica_priority:100
replica_read_only:1
connected_replicas:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
......
doc/administration/high_availability/redis_source.md
View file @ a77d736d
......@@ -40,7 +40,7 @@ This is the section where we install and set up the new Redis instances.
- Since Redis 3.2, you must define a password to receive external connections
(`requirepass`).
- If you are using Redis with Sentinel, you will also need to define the same
password for the slave password definition (`masterauth`) in the same instance.
password for the replica password definition (`masterauth`) in the same instance.
In addition, read the prerequisites as described in the
[Omnibus Redis HA document](redis.md#prerequisites) since they provide some
......@@ -72,9 +72,9 @@ Assuming that the Redis master instance IP is `10.0.0.1`:
1. Restart the Redis service for the changes to take effect.
### Step 2. Configuring the slave Redis instances
### Step 2. Configuring the replica Redis instances
Assuming that the Redis slave instance IP is `10.0.0.2`:
Assuming that the Redis replica instance IP is `10.0.0.2`:
1. [Install Redis](../../install/installation.md#7-redis).
1. Edit `/etc/redis/redis.conf`:
......@@ -95,12 +95,12 @@ Assuming that the Redis slave instance IP is `10.0.0.2`:
requirepass redis-password-goes-here
masterauth redis-password-goes-here
## Define `slaveof` pointing to the Redis master instance with IP and port.
slaveof 10.0.0.1 6379
## Define `replicaof` pointing to the Redis master instance with IP and port.
replicaof 10.0.0.1 6379
```
1. Restart the Redis service for the changes to take effect.
1. Go through the steps again for all the other slave nodes.
1. Go through the steps again for all the other replica nodes.
### Step 3. Configuring the Redis Sentinel instances
......@@ -131,7 +131,7 @@ master with IP `10.0.0.1` (some settings might overlap with the master):
masterauth redis-password-goes-here
## Define with `sentinel auth-pass` the same shared password you have
## defined for both Redis master and slaves instances.
## defined for both Redis master and replicas instances.
sentinel auth-pass gitlab-redis redis-password-goes-here
## Define with `sentinel monitor` the IP and port of the Redis
......@@ -149,18 +149,18 @@ master with IP `10.0.0.1` (some settings might overlap with the master):
## already tried against the same master by a given Sentinel, is two
## times the failover timeout.
##
## * The time needed for a slave replicating to a wrong master according
## * The time needed for a replica replicating to a wrong master according
## to a Sentinel current configuration, to be forced to replicate
## with the right master, is exactly the failover timeout (counting since
## the moment a Sentinel detected the misconfiguration).
##
## * The time needed to cancel a failover that is already in progress but
## did not produced any configuration change (SLAVEOF NO ONE yet not
## acknowledged by the promoted slave).
## did not produced any configuration change (REPLICAOF NO ONE yet not
## acknowledged by the promoted replica).
##
## * The maximum time a failover in progress waits for all the slaves to be
## reconfigured as slaves of the new master. However even after this time
## the slaves will be reconfigured by the Sentinels anyway, but not with
## * The maximum time a failover in progress waits for all the replicas to be
## reconfigured as replicas of the new master. However even after this time
## the replicas will be reconfigured by the Sentinels anyway, but not with
## the exact parallel-syncs progression as specified.
sentinel failover_timeout 30000
```
......@@ -203,7 +203,7 @@ setup:
1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
## Example of minimal configuration with 1 master, 2 slaves and 3 Sentinels
## Example of minimal configuration with 1 master, 2 replicas and 3 Sentinels
In this example we consider that all servers have an internal network
interface with IPs in the `10.0.0.x` range, and that they can connect
......@@ -215,13 +215,13 @@ outside ([Internet](https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353
For this example, **Sentinel 1** will be configured in the same machine as the
**Redis Master**, **Sentinel 2** and **Sentinel 3** in the same machines as the
**Slave 1** and **Slave 2** respectively.
**Replica 1** and **Replica 2** respectively.
Here is a list and description of each **machine** and the assigned **IP**:
- `10.0.0.1`: Redis Master + Sentinel 1
- `10.0.0.2`: Redis Slave 1 + Sentinel 2
- `10.0.0.3`: Redis Slave 2 + Sentinel 3
- `10.0.0.2`: Redis Replica 1 + Sentinel 2
- `10.0.0.3`: Redis Replica 2 + Sentinel 3
- `10.0.0.4`: GitLab application
Please note that after the initial configuration, if a failover is initiated
......@@ -257,7 +257,7 @@ or a failover promotes a different **Master** node.
1. Restart the Redis service for the changes to take effect.
### Example configuration for Redis slave 1 and Sentinel 2
### Example configuration for Redis replica 1 and Sentinel 2
1. In `/etc/redis/redis.conf`:
......@@ -266,7 +266,7 @@ or a failover promotes a different **Master** node.
port 6379
requirepass redis-password-goes-here
masterauth redis-password-goes-here
slaveof 10.0.0.1 6379
replicaof 10.0.0.1 6379
```
1. In `/etc/redis/sentinel.conf`:
......@@ -282,7 +282,7 @@ or a failover promotes a different **Master** node.
1. Restart the Redis service for the changes to take effect.
### Example configuration for Redis slave 2 and Sentinel 3
### Example configuration for Redis replica 2 and Sentinel 3
1. In `/etc/redis/redis.conf`:
......@@ -291,7 +291,7 @@ or a failover promotes a different **Master** node.
port 6379
requirepass redis-password-goes-here
masterauth redis-password-goes-here
slaveof 10.0.0.1 6379
replicaof 10.0.0.1 6379
```
1. In `/etc/redis/sentinel.conf`:
......
doc/development/scalability.md
View file @ a77d736d
......@@ -214,7 +214,7 @@ Redis process.
Single-core: Like PgBouncer, a single Redis process can only use one
core. It does not support multi-threading.
Dumb secondaries: Redis secondaries (aka slaves) don't actually
Dumb secondaries: Redis secondaries (aka replicas) don't actually
handle any load. Unlike PostgreSQL secondaries, they don't even serve
read queries. They simply replicate data from the primary and take over
only when the primary fails.
......@@ -231,8 +231,8 @@ election to determine a new leader.
No leader: A Redis cluster can get into a mode where there are no
primaries. For example, this can happen if Redis nodes are misconfigured
to follow the wrong node. Sometimes this requires forcing one node to
become a primary via the [`SLAVEOF NO ONE`
command](https://redis.io/commands/slaveof).
become a primary via the [`REPLICAOF NO ONE`
command](https://redis.io/commands/replicaof).
### Sidekiq
......
spec/fixtures/config/redis_cache_new_format_host.yml
View file @ a77d736d
......@@ -7,7 +7,7 @@ development:
host: localhost
port: 26380 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26380 # point to sentinel, not to redis port
test:
url: redis://:mynewpassword@localhost:6380/10
......@@ -16,14 +16,14 @@ test:
host: localhost
port: 26380 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26380 # point to sentinel, not to redis port
production:
url: redis://:mynewpassword@localhost:6380/10
sentinels:
-
host: slave1
host: replica1
port: 26380 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26380 # point to sentinel, not to redis port
spec/fixtures/config/redis_new_format_host.yml
View file @ a77d736d
......@@ -7,7 +7,7 @@ development:
host: localhost
port: 26379 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26379 # point to sentinel, not to redis port
test:
url: redis://:mynewpassword@localhost:6379/99
......@@ -16,14 +16,14 @@ test:
host: localhost
port: 26379 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26379 # point to sentinel, not to redis port
production:
url: redis://:mynewpassword@localhost:6379/99
sentinels:
-
host: slave1
host: replica1
port: 26379 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26379 # point to sentinel, not to redis port
spec/fixtures/config/redis_queues_new_format_host.yml
View file @ a77d736d
......@@ -7,7 +7,7 @@ development:
host: localhost
port: 26381 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26381 # point to sentinel, not to redis port
test:
url: redis://:mynewpassword@localhost:6381/11
......@@ -16,14 +16,14 @@ test:
host: localhost
port: 26381 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26381 # point to sentinel, not to redis port
production:
url: redis://:mynewpassword@localhost:6381/11
sentinels:
-
host: slave1
host: replica1
port: 26381 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26381 # point to sentinel, not to redis port
spec/fixtures/config/redis_shared_state_new_format_host.yml
View file @ a77d736d
......@@ -7,7 +7,7 @@ development:
host: localhost
port: 26382 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26382 # point to sentinel, not to redis port
test:
url: redis://:mynewpassword@localhost:6382/12
......@@ -16,14 +16,14 @@ test:
host: localhost
port: 26382 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26382 # point to sentinel, not to redis port
production:
url: redis://:mynewpassword@localhost:6382/12
sentinels:
-
host: slave1
host: replica1
port: 26382 # point to sentinel, not to redis port
-
host: slave2
host: replica2
port: 26382 # point to sentinel, not to redis port
spec/support/redis/redis_shared_examples.rb
View file @ a77d736d
......@@ -150,7 +150,7 @@ RSpec.shared_examples "redis_shared_examples" do
it 'returns an array of hashes with host and port keys' do
is_expected.to include(host: 'localhost', port: sentinel_port)
is_expected.to include(host: 'slave2', port: sentinel_port)
is_expected.to include(host: 'replica2', port: sentinel_port)
end
end
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7