Redis Exploration

Read the SONiC database mapping, list the databases by name and id, query selected tables using targeted keys and SCAN, compare CONFIG_DB (intent) against STATE_DB (observed), then make one safe config change and watch exactly which keys move.

  database container → redis-server
    ├─ CONFIG_DB   (intent)
    ├─ APPL_DB     (application/plan)
    ├─ ASIC_DB     (hardware-facing intent)
    ├─ STATE_DB    (observed)
    └─ COUNTERS_DB (stats)

Prerequisites: Lesson 1.4 complete. · Baseline snapshot available for rollback.

Tasks

1. 1

   Read the database mapping (do not assume ids)

   The name→id/instance mapping lives in database_config.json; read it rather than hardcoding a number.

   Linuxauthoritative name→id mapping Copy

   cat /var/run/redis/sonic-db/database_config.json

   Expected:

   • A JSON mapping each DB name (CONFIG_DB, APPL_DB, …) to an id and redis instance. Note the ids — they can differ by version/vendor.

   What happened internally: sonic-db-cli uses this mapping to resolve names to ids, which is why you should call databases by name, not number.

2. 2

   Query a table with a targeted key

   SONiC DB Copy

   sonic-db-cli CONFIG_DB HGETALL "PORT|Ethernet0"

   Expected:

   • The intent fields for that port (alias, admin_status, speed, …).

   What happened internally: A targeted HGETALL touches exactly one key — no keyspace walk, no blocking. This is the safe default.

3. 3

   Walk a keyspace with SCAN (never KEYS *)

   Use SCAN with a MATCH pattern to enumerate incrementally. Do NOT run KEYS * — on a large DB it blocks redis-server and can stall dependent services.

   SONiC DB Copy

   sonic-db-cli APPL_DB SCAN 0 MATCH "PORT_TABLE:*" COUNT 50

   Expected:

   • A cursor plus a partial list of matching keys; repeat with the returned cursor until it is 0.

   What happened internally: SCAN is cursor-based and non-blocking; it trades a single big pause for many tiny increments — production-safe.

4. 4

   Compare intent (CONFIG_DB) vs observed (STATE_DB)

   Look at the same port in CONFIG_DB (what you asked for) and STATE_DB (what is actually true).

   SONiC DB Copy

   sonic-db-cli CONFIG_DB HGETALL "PORT|Ethernet0"

   SONiC DBobserved state (key/table names are version-dependent) Copy

   sonic-db-cli STATE_DB HGETALL "PORT_TABLE|Ethernet0"

   Expected:

   • CONFIG_DB shows desired admin_status; STATE_DB shows observed oper_status/speed. They can legitimately differ.

   What happened internally: This is the desired-vs-observed split made concrete. A mismatch here is exactly what localizes a fault in Lesson 1.5's flow.

5. 5

   Make ONE safe change and watch the keys move

   Set a description on an unused, admin-down port (a non-forwarding-affecting field), then re-read CONFIG_DB. Exact CLI is version-dependent; if config interface description is unavailable, note that and observe an equivalent low-risk field. Remove the change afterward.

   SONiC CLIversion-dependent; low-risk metadata field Copy

   sudo config interface description Ethernet0 'lab-1-3-test'

   SONiC DB Copy

   sonic-db-cli CONFIG_DB HGETALL "PORT|Ethernet0"

   Expected:

   • The CONFIG_DB PORT|Ethernet0 hash now includes the new description field; STATE_DB oper state is unchanged (metadata does not affect forwarding).

   What happened internally: You just watched intent land in CONFIG_DB. Because the field is metadata, nothing propagates to the ASIC — a clean illustration that CONFIG_DB writes are the *start* of the flow, not the end.