1
0
mirror of https://github.com/redis/go-redis.git synced 2025-11-30 18:01:23 +03:00
Files
go-redis/example/disable-maintnotifications
ofekshenawa f711eb0f62 feat(cluster): Implement Request and Response Policy Based Routing in Cluster Mode (#3422)
* Add search module builders and tests (#1)

* Add search module builders and tests

* Add tests

* Use builders and Actions in more clean way

* Update search_builders.go

Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>

* Update search_builders.go

Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>

* Apply suggestions from code review

Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>

* feat(routing): add internal request/response policy enums

* feat: load the policy table in cluster client (#4)

* feat: load the policy table in cluster client

* Remove comments

* modify Tips and command pplicy in commandInfo (#5)

* centralize cluster command routing in osscluster_router.go and refactor osscluster.go (#6)

* centralize cluster command routing in osscluster_router.go and refactor osscluster.go

* enalbe ci on all branches

* Add debug prints

* Add debug prints

* FIX: deal with nil policy

* FIX: fixing clusterClient process

* chore(osscluster): simplify switch case

* wip(command): ai generated clone method for commands

* feat: implement response aggregator for Redis cluster commands

* feat: implement response aggregator for Redis cluster commands

* fix: solve concurrency errors

* fix: solve concurrency errors

* return MaxRedirects settings

* remove locks from getCommandPolicy

* Handle MOVED errors more robustly, remove cluster reloading at exectutions, ennsure better routing

* Fix: supports Process hook test

* Fix: remove response aggregation for single shard commands

* Add more preformant type conversion for Cmd type

* Add router logic into processPipeline

---------

Co-authored-by: Nedyalko Dyakov <nedyalko.dyakov@gmail.com>

* remove thread debugging code

* remove thread debugging code && reject commands with policy that cannot be used in pipeline

* refactor processPipline and cmdType enum

* remove FDescribe from cluster tests

* Add tests

* fix aggregation test

* fix mget test

* fix mget test

* remove aggregateKeyedResponses

* added scaffolding for the req-resp manager

* added default policies for the search commands

* split command map into module->command

* cleanup, added logic to refresh the cache

* added reactive cache refresh

* revert cluster refresh

* fixed lint

* addresed first batch of comments

* rewrote aggregator implementations with atomic for native or nearnative primitives

* addressed more comments, fixed lint

* added batch aggregator operations

* fixed lint

* updated batch aggregator, fixed extractcommandvalue

* fixed lint

* added batching to aggregateResponses

* fixed deadlocks

* changed aggregator logic, added error params

* added preemptive return to the aggregators

* more work on the aggregators

* updated and and or aggregators

* fixed lint

* added configurable policy resolvers

* slight refactor

* removed the interface, slight refactor

* change func signature from cmdName to cmder

* added nil safety assertions

* few small refactors

* added read only policies

* removed leftover prints

* Rebased to master, resolved comnflicts

* fixed lint

* updated gha

* fixed tests, minor consistency refactor

* preallocated simple errors

* changed numeric aggregators to use float64

* speculative test fix

* Update command.go

Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>

* Update main_test.go

Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>

* Add static shard picker

* Fix nil value handling in command aggregation

* Modify the Clone method to return a shallow copy

* Add clone method to digest command

* Optimize keyless command routing to respect ShardPicker policy

* Remove MGET references

* Fix MGET aggregation to map individual values to keys across shards

* Add clone method to hybrid search commands

* Undo changes in route keyless test

* remove comments

* Add test for DisableRoutingPolicies option

* Add Routing Policies Comprehensive Test Suite and Fix multi keyed aggregation for different step

---------

Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>
Co-authored-by: Nedyalko Dyakov <nedyalko.dyakov@gmail.com>
Co-authored-by: Hristo Temelski <hristo.temelski@redis.com>
2025-11-28 11:46:23 +02:00
..

Disable Maintenance Notifications Example

This example demonstrates how to use the go-redis client with maintenance notifications disabled.

What are Maintenance Notifications?

Maintenance notifications are a Redis Cloud feature that allows the server to notify clients about:

  • Planned maintenance events
  • Failover operations
  • Node migrations
  • Cluster topology changes

The go-redis client supports three modes:

  • ModeDisabled: Client doesn't send CLIENT MAINT_NOTIFICATIONS ON command
  • ModeEnabled: Client forcefully sends the command, interrupts connection on error
  • ModeAuto (default): Client tries to send the command, disables feature on error

When to Disable Maintenance Notifications

You should disable maintenance notifications when:

  1. Connecting to non-Redis Cloud / Redis Enterprise instances - Standard Redis servers don't support this feature
  2. You want to handle failovers manually - Your application has custom failover logic
  3. Minimizing client-side overhead - You want the simplest possible client behavior
  4. The Redis server doesn't support the feature - Older Redis versions or forks

Usage

Basic Example

import (
    "github.com/redis/go-redis/v9"
    "github.com/redis/go-redis/v9/maintnotifications"
)

rdb := redis.NewClient(&redis.Options{
    Addr: "localhost:6379",

    // Explicitly disable maintenance notifications
    MaintNotificationsConfig: &maintnotifications.Config{
        Mode: maintnotifications.ModeDisabled,
    },
})
defer rdb.Close()

Cluster Client Example

rdbCluster := redis.NewClusterClient(&redis.ClusterOptions{
    Addrs: []string{"localhost:7000", "localhost:7001", "localhost:7002"},

    // Disable maintenance notifications for cluster
    MaintNotificationsConfig: &maintnotifications.Config{
        Mode: maintnotifications.ModeDisabled,
    },
})
defer rdbCluster.Close()

Default Behavior (ModeAuto)

If you don't specify MaintNotifications, the client defaults to ModeAuto:

// This uses ModeAuto by default
rdb := redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
    // MaintNotificationsConfig: nil means ModeAuto
})

With ModeAuto, the client will:

  1. Try to enable maintenance notifications
  2. If the server doesn't support it, silently disable the feature
  3. Continue normal operation

Running the Example

  1. Start a Redis server:

    redis-server --port 6379
    
  2. Run the example:

    go run main.go
    

Expected Output

=== Example 1: Explicitly Disabled ===
✓ Connected successfully (maintenance notifications disabled)
✓ SET operation successful
✓ GET operation successful: value1

=== Example 2: Default Behavior (ModeAuto) ===
✓ Connected successfully (maintenance notifications auto-enabled)

=== Example 3: Cluster Client with Disabled Notifications ===
Cluster not available (expected): ...

=== Example 4: Performance Comparison ===
✓ 1000 SET operations (disabled): 45ms
✓ 1000 SET operations (auto): 46ms

=== Cleanup ===
✓ Database flushed

=== Summary ===
Maintenance notifications can be disabled by setting:
  MaintNotificationsConfig: &maintnotifications.Config{
    Mode: maintnotifications.ModeDisabled,
  }

This is useful when:
  - Connecting to non-Redis Cloud instances
  - You want to handle failovers manually
  - You want to minimize client-side overhead
  - The Redis server doesn't support CLIENT MAINT_NOTIFICATIONS

Performance Impact

Disabling maintenance notifications has minimal performance impact. The main differences are:

  1. Connection Setup: One less command (CLIENT MAINT_NOTIFICATIONS ON) during connection initialization
  2. Runtime Overhead: No background processing of maintenance notifications
  3. Memory Usage: Slightly lower memory footprint (no notification handlers)

In most cases, the performance difference is negligible (< 1%).