From bbe41b7edf952e829f4d59f5ecb4f6d0175a1701 Mon Sep 17 00:00:00 2001 From: Petya Slavova Date: Mon, 27 Oct 2025 15:01:08 +0200 Subject: [PATCH 1/2] Adding Redis 8.4 RC1 image to test matrix. --- .github/workflows/integration.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/integration.yaml b/.github/workflows/integration.yaml index 5adf7f41ac..36a1de0d63 100644 --- a/.github/workflows/integration.yaml +++ b/.github/workflows/integration.yaml @@ -76,7 +76,7 @@ jobs: max-parallel: 15 fail-fast: false matrix: - redis-version: ['8.4-M01-pre', '${{ needs.redis_version.outputs.CURRENT }}', '8.0.2' ,'7.4.4', '7.2.9'] + redis-version: ['8.4-RC1-pre', '${{ needs.redis_version.outputs.CURRENT }}', '8.0.2' ,'7.4.4', '7.2.9'] python-version: ['3.9', '3.13'] parser-backend: ['plain'] event-loop: ['asyncio'] From edd522dd7e32df6c9165e6e30dea166c2cf53cae Mon Sep 17 00:00:00 2001 From: Petya Slavova Date: Wed, 29 Oct 2025 10:17:03 +0200 Subject: [PATCH 2/2] Fix spelling error. --- docs/multi_database.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/multi_database.rst b/docs/multi_database.rst index 2eb1b2cdb2..97becef27c 100644 --- a/docs/multi_database.rst +++ b/docs/multi_database.rst @@ -1,9 +1,9 @@ Multi-database client (Active-Active) ===================================== -The multi-database client allows your application to connect to multiple Redis databases, which are typically replicas of each other. -It is designed to work with Redis Software and Redis Cloud Active-Active setups. -The client continuously monitors database health, detects failures, and automatically fails over to the next healthy database using a configurable strategy. +The multi-database client allows your application to connect to multiple Redis databases, which are typically replicas of each other. +It is designed to work with Redis Software and Redis Cloud Active-Active setups. +The client continuously monitors database health, detects failures, and automatically fails over to the next healthy database using a configurable strategy. When the original database becomes healthy again, the client can automatically switch back to it. Key concepts @@ -29,7 +29,7 @@ Key concepts fine-grain tuned configuration of triggering fail over based on organic traffic. - Failover strategy: - The default strategy is based on staticly configured weights. It prefers the highest weighted healthy database. + The default strategy is based on statically configured weights. It prefers the highest weighted healthy database. - Command retry: Command execution supports retry with backoff. Low-level client retries are disabled and a global retry @@ -269,9 +269,9 @@ configuration defined in the `MultiDBConfig` class. To avoid false positives, you can configure amount of health check probes and also define one of the health check policies to evaluate probes result. -**HealthCheckPolicies.HEALTHY_ALL** - (default) All probes should be successful. -**HealthCheckPolicies.HEALTHY_MAJORITY** - Majority of probes should be successful. -**HealthCheckPolicies.HEALTHY_ANY** - Any of probes should be successful. +**HealthCheckPolicies.HEALTHY_ALL** - (default) All probes should be successful. +**HealthCheckPolicies.HEALTHY_MAJORITY** - Majority of probes should be successful. +**HealthCheckPolicies.HEALTHY_ANY** - Any of probes should be successful. PingHealthCheck (default) ^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -357,8 +357,8 @@ You can add custom health checks for specific requirements: Failure Detection (Reactive Monitoring) ----------------- -The failure detector monitors command failures and marks a database as unhealthy when its failure rate exceeds a defined threshold within a sliding time window. -Under real traffic conditions, this reactive detection mechanism likely triggers earlier than proactive health checks. +The failure detector monitors command failures and marks a database as unhealthy when its failure rate exceeds a defined threshold within a sliding time window. +Under real traffic conditions, this reactive detection mechanism likely triggers earlier than proactive health checks. You can extend the set of failure detectors by implementing your own and configuring it through the `MultiDBConfig` class. By default the failure detector is configured for 1000 failures and a 10% failure rate