How does a Redis 7 server-side function library get onto every node of a deployment — what happens on FUNCTION LOAD with respect to replicas, snapshots and restarts, and which commands would you use to inspect or move the installed libraries?

## Loading is a state change, not a connection setting The mental shift from EVAL is this: `SCRIPT LOAD` only touched an in-memory, per-node cache that no one persisted; `FUNCTION LOAD` changes durable server state. Redis treats a library like data. Concretely, when you run `FUNCTION LOAD [REPLACE] <code>` on a primary: 1. The code is parsed, the shebang read, the library instantiated and its functions registered. Any error here aborts the whole load — a library is all-or-nothing. 2. The command is **propagated to replicas** and to the AOF, so the replicas load the same library. 3. From then on, the library is part of what gets serialized into the **RDB** file. ## What that buys you at restart and failover - **Restart**: loading the RDB (or replaying the AOF) restores libraries. Your application does not need a bootstrap step on reconnect. - **Full resync**: when a replica does a full synchronization, it loads the primary's RDB, which contains the libraries. - **Failover**: the promoted replica already has them. This is the sharp contrast with `EVALSHA`, where the new primary's script cache is typically cold and the first `EVALSHA` returns `NOSCRIPT` until some client reloads the source. ## Cluster: one load per shard Redis Cluster is a set of independent replication groups. A library loaded on shard A's primary reaches only shard A's replicas. Deployment therefore means iterating over every primary and loading there (`redis-cli --cluster call` style loops, or a config-management step). Two operational consequences: - **Drift is possible.** One shard can end up on an old library version if a load partially failed. `FUNCTION LIST WITHCODE` on every node, hashed and compared, is the drift check. - **New nodes need seeding.** A node added during a reshard has no libraries; add the load to your node-provisioning procedure, or use `FUNCTION DUMP`/`RESTORE` from a known-good node. ## The management surface - `FUNCTION LIST [LIBRARYNAME <name>] [WITHCODE]` — libraries, engine, registered functions and their flags; `WITHCODE` returns the source, which makes the server self-describing and lets you diff deployed code against your repository. - `FUNCTION STATS` — whether a function is running right now (its name and how long it has been executing) plus per-engine counts of libraries and functions. This is your first stop when clients report `BUSY`. - `FUNCTION DUMP` — a binary payload of **all** libraries on the node. `FUNCTION RESTORE <payload> [APPEND|FLUSH|REPLACE]` loads it elsewhere: `APPEND` (default) fails on name collisions, `FLUSH` clears existing libraries first, `REPLACE` overwrites colliding ones. This is the supported way to clone a node's function set, including into a fresh environment. - `FUNCTION DELETE <libname>` and `FUNCTION FLUSH [ASYNC|SYNC]` — removal; both replicate, so a `FUNCTION FLUSH` on a primary wipes the replicas too. Treat it with the same care as `FLUSHALL` for code. - `FUNCTION KILL` — terminate a currently running function, only if it has performed no write. ## Deployment patterns Because the library is versionless from Redis's point of view, versioning is a naming convention you impose. Two common approaches: 1. **In-place upgrade**: `FUNCTION LOAD REPLACE` the same library name. Simple, but the swap is instantaneous and old and new callers cannot coexist — only safe when the function contract is unchanged. 2. **Side-by-side**: load `orders_v2` alongside `orders_v1` with distinct function names, shift application traffic, then `FUNCTION DELETE orders_v1`. This gives you a rollback that is just a config flip, at the cost of a name-management convention. Note function names are unique **server-wide**, so v2's functions must be named distinctly. Whichever you choose, the load belongs in your deployment pipeline next to schema migrations, with the source in version control. `FUNCTION LIST WITHCODE` then serves as the audit that the fleet matches the repo. ## Things that bite - Loading on a **replica** directly is refused (replicas are read-only); always load on primaries. - `FUNCTION LOAD` without `REPLACE` errors on an existing name — a re-run of a deployment script must use `REPLACE` or tolerate that error. - A `FUNCTION FLUSH` propagates; it is not a local cleanup. - Managed Redis services and proxies may restrict or intercept `FUNCTION` subcommands; verify before designing around them. - RDB files containing libraries are only loadable by a version that understands them, so a downgrade below 7.0 will not read them.