title: Dynatrace with Redis Software

summary: To collect, view, and monitor metrics data from your databases and other cluster components, you can connect Dynatrace to your Redis Software cluster using the Redis Dynatrace Integration.

title: Overview

text:
[Dynatrace](https://www.dynatrace.com/) is used by organizations of all sizes and across a wide range of industries to
enable digital transformation and cloud migration, drive collaboration among development, operations, security and
business teams, accelerate time to market for applications, reduce time to problem resolution, secure applications and
infrastructure, understand user behavior, and track key business metrics.

The Dynatrace Integration for Redis Software uses Prometheus remote write functionality to connect Prometheus data
sources to Dynatrace. This integration enables Redis Software users to export metrics to Dynatrace for analysis,
and includes Redis-designed dashboards for use in monitoring Redis Software clusters.

This integration makes it possible to:
- Collect and display metrics not available in the admin console
- Set up automatic alerts for node or cluster events
- Display these metrics alongside data from other systems

title: Install Redis' Dynatrace Integration for Redis Software

text:
At the present time the Dynatrace integration is not signed by Dynatrace, meaning that it will be necessary to download
the source configuration and dashboards and assemble them and sign them cryptologically with a certificate that you have
created. The instructions for this procedure can be found on the Dynatrace
[site](https://docs.dynatrace.com/docs/extend-dynatrace/extensions20/sign-extension). Please note that the instructions
would have you place the dashboards next to the src folder; this is incorrect, the dashboards should be located inside
the src folder.

title: View metrics

text:
The Redis Software Integration for Dynatrace contains pre-defined dashboards to aid in monitoring your Redis Software deployment.

The following dashboards are currently available:

- Cluster: top-level statistics indicating the general health of the cluster
- Database: performance metrics at the database level
- Node: machine performance statistics
- Shard: low-level details of an individual shard
- Active-Active: replication and performance for geo-replicated clusters
- Proxy: network and command information regarding the proxy
- Proxy Threads: processor usage information regarding the proxy's component threads

title: Monitor metrics

text:
Dynatrace dashboards can be filtered using the text area. For example, when viewing a cluster dashboard it is possible to
filter the display to show data for only one cluster by typing 'cluster' in the text area and waiting for the system to
retrieve the relevant data before choosing one of the options in the 'cluster' section.

Certain types of data do not know the name of the database from which they were drawn. The dashboard should have a list
of database names and ids; use the id value when filtering input to the dashboard.


title: FusionCache for C#/.NET

summary: Easy to use, fast and robust hybrid cache with advanced resiliency features for C#/.NET

page_type: content

title: Overview

role: overview

text: FusionCache can transparently handle multiple cache levels by mixing a memory cache and a distributed cache together, getting the best of both worlds. It allows for a sophisticated yet incredibly easy to use developer experience by handling all the complexities of a modern, fast and robust hybrid cache that can deal with the most complex and demanding scenarios. When coupled with Redis, performance, robustness and scaling will not be a problem anymore.

title: Key Features

role: content

text:
- **Hybrid**: Can be used as both L1 (memory only) or L1+L2 (memory + distributed)
- **Tagging**: Powerful tagging capabilities to easily work with multiple entries at once
- **Backplane**: For instant multi-node distributed notifications
- **Stampede Protection**: Both on single node (with a memory locker) and multi-node (with a distributed locker)
- **Redis Perfect Match**: Native support for all distributed parts (cache, backplane and locker)
- **Resiliency**: Fully resilient thanks to features like Fail-Safe, Eager Refresh, Factory Timeouts, Auto-Recovery and more
- **Sync+Async**: Full support for both programming models
- **.NET Ecosystem**: Seamless integration with ASP.NET Core, Entity Framework, and other .NET technologies

title: Install

role: setup

text:
Using the dotnet CLI, run:

[code example]

Other packages are also available to work with different distributed caches, serializers, backplanes and more.
See the [FusionCache docs](https://github.com/ZiggyCreatures/FusionCache/blob/main/docs/README.md) for more information.

title: Getting Started

text:
First, install the packages for Redis (with JSON serialization):

[code example]

Then at startup:

[code example]

Use code like the following to share the Redis connection multiplexer:

[code example]

FusionCache is now ready to use. The simple example below demonstrates the `GetOrSetAsync` method but see [Core Methods](https://github.com/ZiggyCreatures/FusionCache/blob/main/docs/CoreMethods.md) in the FusionCache docs for full details of the API.

[code example]

title: Further Reading

text:
To learn more about FusionCache and its advanced features:

- [FusionCache Documentation](https://github.com/ZiggyCreatures/FusionCache)
- [FusionCache NuGet Package](https://www.nuget.org/packages/ZiggyCreatures.FusionCache)
- [Redis Backplane Package](https://www.nuget.org/packages/ZiggyCreatures.FusionCache.Backplane.StackExchangeRedis)

section_id: install

code:
dotnet add package ZiggyCreatures.FusionCache
dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis
dotnet add package ZiggyCreatures.FusionCache.Serialization.SystemTextJson
dotnet add package ZiggyCreatures.FusionCache.Backplane.StackExchangeRedis

section_id: getting-started

code:
services.AddFusionCache()
    .WithSerializer(
        new FusionCacheSystemTextJsonSerializer()
    )
    .WithDistributedCache(
        new RedisCache(new RedisCacheOptions { Configuration = "localhost:6379" })
    )
    .WithBackplane(
        new RedisBackplane(new RedisBackplaneOptions { Configuration = "localhost:6379" })
    );

code:
var muxer = ConnectionMultiplexer.Connect("localhost:6379")

services.AddFusionCache()
    .WithSerializer(
        new FusionCacheSystemTextJsonSerializer()
    )
    .WithDistributedCache(
        new RedisCache(new RedisCacheOptions { ConnectionMultiplexerFactory = () => muxer })
    )
    .WithBackplane(
        new RedisBackplane(new RedisBackplaneOptions { ConnectionMultiplexerFactory = () => muxer })
    );

code:
var product1 = await cache.GetOrSetAsync<Product>(
    "product:1",
    async _ => GetProductFromDb(1),
    tags: ["sales", "product"]
);

var product2 = await cache.GetOrSetAsync<Product>(
    "product:2",
    async _ => GetProductFromDb(2),
    tags: ["sales", "product"]
);

var order = await cache.GetOrSetAsync<Order>(
    "order:42",
    async _ => GetOrderFromDb(42),
    tags: ["sales", "order"]
);

// LATER...

await cache.RemoveByTagAsync("product");

// NOW BOTH product:1 AND product:2 ARE GONE, ONLY order:42 IS STILL IN THE CACHE


title: Redis Cloud on Google Cloud

title: Overview

text: Deploy Redis Cloud on Google Cloud Platform (GCP) to leverage Redis's performance with Google's scalable cloud infrastructure and AI/ML services.

title: Overview

text: Redis Cloud on Google Cloud provides a fully managed Redis service that integrates with Google's advanced cloud platform and AI/ML services. Deploy Redis databases across Google's global network with enterprise security, automatic scaling, and seamless GCP integrations.

title: Key Features

text:
- **Private Service Connect**: Secure, private connectivity within Google Cloud
- **Global Network**: Deploy across Google's worldwide network of regions
- **Auto-scaling**: Intelligent scaling based on traffic patterns and usage
- **Enterprise Security**: Google Cloud IAM integration and advanced security features

title: Getting Started

text: Get started with [Redis Cloud]() on Google Cloud to create and manage your Redis databases.


title: Go client for Redis

summary: Learn how to build with Redis and Go

title: Overview

text: Connect your Go application to a Redis database using the go-redis client library.

title: Overview

text: go-redis is a type-safe, Redis client library for Go that supports Redis 6.0+ features including Redis Cluster, Redis Sentinel, and Redis streams. It provides a clean, idiomatic Go API for interacting with Redis.

title: Key Features

text:
- **Type Safety**: Strongly typed commands and responses
- **Redis Cluster Support**: Built-in support for Redis Cluster deployments
- **Redis Sentinel**: Automatic failover with Redis Sentinel
- **Pipelining**: Efficient command batching for improved performance
- **Pub/Sub**: Real-time messaging with Redis Pub/Sub
- **Streams**: Support for Redis Streams data structure
- **Connection Pooling**: Automatic connection management
- **Context Support**: Full context.Context integration for cancellation and timeouts

title: Getting Started

text: Refer to the complete [Go guide]() to install, connect, and use go-redis with detailed examples and best practices.


title: Redis Cloud on Heroku

summary: Deploy Redis Cloud as a Heroku add-on

page_type: index


title: C client for Redis

summary: Learn how to build with Redis and C

title: Overview

text: Connect your C application to a Redis database using the hiredis client library.

title: Overview

text: hiredis is a minimalistic C client library for Redis that provides a simple, efficient interface for Redis operations. It's designed to be lightweight, fast, and easy to integrate into C applications with minimal dependencies.

title: Key Features

text:
- **Lightweight**: Minimal memory footprint and dependencies
- **High Performance**: Optimized for speed and low latency
- **Synchronous & Asynchronous**: Support for both blocking and non-blocking operations
- **Pipeline Support**: Efficient command batching for improved throughput
- **Error Handling**: Comprehensive error reporting and handling
- **Cross-platform**: Works on Linux, macOS, Windows, and embedded systems
- **Thread Safe**: Safe for use in multi-threaded applications
- **Simple API**: Clean, straightforward C interface

title: Getting Started

text: Refer to the complete [C guide]() to install, connect, and use hiredis.


title: Libraries and tools

title: Redis Data Integration

summary: Visual client tool for creating, managing, and analyzing Redis databases

title: Redis Insight

summary: Access a Redis server using any MCP client.

title: Redis MCP

summary: Learn how to build with Redis and Python

title: Python client for Redis

summary: This is the Redis vector library (RedisVL).

title: RedisVL

summary: Redis Input/Output Tools

title: RIOT

summary: Learn how to build with Redis and Java

title: Java client for Redis

summary: Learn how to build with Redis and Java

title: Java client for Redis

summary: Learn how to build with Redis and Node.js

title: Node.js client for Redis

summary: Learn how to build with Redis and C#/.NET

title: C#/.NET client for Redis

summary: Shows how to use your Redis database with Amazon Bedrock to customize foundational models.

title: Amazon Bedrock

summary: Learn how to build with Redis and Go

title: Go client for Redis

summary: Learn how to use Redis as a vector store with n8n workflows

title: n8n Redis vector store

summary: Learn how to build with Redis and PHP

title: PHP client for Redis

summary: Explains how to use Pulumi to provision Redis Cloud infrastructure

title: Pulumi provider for Redis Cloud

title: Terraform provider for Redis Cloud

summary: Learn how to build with Redis and C

title: C client for Redis

summary: Use Prometheus and Grafana to collect and visualize Redis Software metrics.

title: Prometheus and Grafana with Redis Software

summary: Build AI applications with Redis vector database and semantic caching

title: Redis for AI

summary: Use Prometheus and Grafana to collect and visualize Redis Cloud metrics.

title: Prometheus and Grafana with Redis Cloud

summary: To collect, view, and monitor metrics data from your databases and other cluster components, you can connect Datadog to your Redis Cloud cluster using the Redis Datadog Integration.

title: Datadog with Redis Cloud

summary: To collect, view, and monitor metrics data from your databases and other cluster components, you can connect Datadog to your Redis Software cluster using the Redis Datadog Integration.

title: Datadog with Redis Software

summary: To collect, view, and monitor metrics data from your databases and other cluster components, you can connect Dynatrace to your Redis Cloud cluster using the Redis Dynatrace Integration.

title: Dynatrace with Redis Cloud

title: Dynatrace with Redis Software

summary: The Redis Software (RS) Nagios plugin enables you to monitor the status of RS related objects and alerts. The RS alerts can be related to the cluster, nodes, or databases.

title: Nagios with Redis Software

summary: To collect, view, and monitor metrics data from your databases and other cluster components, you can connect New Relic to your Redis Cloud cluster using the Redis New Relic Integration.

title: New Relic with Redis Cloud

summary: To collect, view, and monitor metrics data from your databases and other cluster components, you can connect New Relic to your Redis Software cluster using the Redis New Relic Integration.

title: New Relic with Redis Software

summary: Deploy and host Redis on Railway. The Railway Redis database template allows you to provision and connect to a Redis database with zero configuration.

title: Redis on Railway

summary: To collect, view, and monitor metrics data from your databases and other cluster components, you can connect Uptrace to your Redis Software cluster using OpenTelemetry Collector.

title: Uptrace with Redis Software

summary: Describes how to integrate Redis Cloud into Confluent Cloud.

title: Confluent with Redis Cloud

summary: Plug Redis into your Spring application with minimal effort

title: Spring Data Redis

title: FusionCache for C#/.NET

summary: Learn how to build with Redis Stack and .NET

title: RedisOM for .NET

summary: Learn how to build with Redis Stack and Spring

title: RedisOM for Java

summary: Learn how to build with Redis Stack and Node.js

title: RedisOM for Node.js

summary: Learn how to build with Redis Stack and Python

title: RedisOM for Python

summary: Learn how to build with Redis and Rust

title: Rust client for Redis

summary: Deploy Redis Cloud on Amazon Web Services

title: Redis Cloud on AWS

summary: Deploy Redis Cloud on Microsoft Azure

title: Redis Cloud on Azure

summary: Deploy Redis Cloud on Google Cloud Platform

title: Redis Cloud on Google Cloud

summary: Integrate Redis with Vercel for fast, scalable web applications

title: Redis with Vercel

summary: Deploy Redis Cloud as a Heroku add-on

title: Redis Cloud on Heroku

summary: Deploy and manage Redis on Kubernetes

title: Redis on Kubernetes

summary: Run Redis Software in Docker containers

title: Redis Software with Docker

summary: Build AI applications with Redis and LangChain

title: Redis with LangChain


title: Java client for Redis

summary: Learn how to build with Redis and Java

title: Overview

text: Connect your Java application to a Redis database using the Jedis client library.

title: Overview

text: Jedis is a popular Java client for Redis that provides a simple, synchronous interface for Redis operations. It offers comprehensive Redis command support and is widely used in Java applications for its straightforward API and reliable performance.

title: Key Features

text:
- **Synchronous Operations**: Simple, blocking API that's easy to understand and use
- **Complete Redis Support**: Full coverage of all Redis commands and data types
- **Connection Pooling**: Built-in connection pool management for multi-threaded applications
- **Redis Cluster**: Native support for Redis Cluster deployments
- **Sentinel Support**: High availability with Redis Sentinel integration
- **Pipeline Support**: Command batching for improved performance
- **Pub/Sub**: Real-time messaging with Redis publish/subscribe
- **Thread Safety**: Safe connection pooling for concurrent Java applications

title: Getting Started

text: Refer to the complete [Jedis guide]() to install, connect, and use Jedis.


title: Redis on Kubernetes

summary: Deploy and manage Redis on Kubernetes

title: Overview

text: Deploy and manage Redis on Kubernetes using Redis Enterprise Operator and Helm charts for scalable containerized deployments.

title: Overview

text: Redis on Kubernetes provides cloud-native Redis deployments using the Redis Enterprise Operator and Helm charts. Perfect for containerized applications requiring high availability, automatic scaling, and seamless integration with Kubernetes ecosystems.

title: Key Features

text:
- **Redis Enterprise Operator**: Kubernetes-native operator for automated Redis management
- **Helm Charts**: Easy deployment and configuration management
- **Auto-scaling**: Automatic scaling based on resource usage and demand
- **High Availability**: Multi-zone deployments with automatic failover
- **Persistent Storage**: Integration with Kubernetes persistent volumes
- **Service Discovery**: Native Kubernetes service discovery and load balancing
- **Resource Management**: CPU and memory limits with Kubernetes resource controls
- **Monitoring Integration**: Prometheus and Grafana integration for observability

title: Getting Started

text: Learn how to [deploy Redis on Kubernetes]() for cloud-native applications.


title: Redis with LangChain

title: Overview

text: Integrate Redis with LangChain to build powerful AI applications with vector search, semantic caching, and conversation memory.

title: Overview

text: Redis integration with LangChain enables you to build sophisticated AI applications with persistent memory, vector search capabilities, and semantic caching. Perfect for chatbots, recommendation systems, and AI-powered applications requiring fast data retrieval.

title: Key Features

text:
- **Vector Search**: High-performance similarity search for embeddings and AI models
- **Conversation Memory**: Persistent chat history and context for AI conversations
- **Semantic Caching**: Cache AI model responses for faster inference and cost reduction
- **Document Storage**: Store and retrieve documents for retrieval-augmented generation (RAG)
- **Real-time Updates**: Live data updates for dynamic AI applications
- **Scalable Architecture**: Handle large-scale AI workloads with Redis performance
- **Multi-modal Support**: Support for text, image, and other data types
- **LangChain Integration**: Native integration with LangChain's ecosystem and tools

title: Getting Started

text: Learn how to [build AI chatbots with Redis and LangChain](https://redis.io/learn/howtos/solutions/vector/gen-ai-chatbot) for enhanced AI experiences.


title: Java client for Redis

summary: Learn how to build with Redis and Java

title: Content

text:
Connect your Java application to a Redis database using the Lettuce client library.

Refer to the complete [Lettuce guide]() to install, connect, and use Lettuce.


title: n8n Redis vector store

summary: Learn how to use Redis as a vector store with n8n workflows

title: Overview

text:
[n8n](https://n8n.io/) is a platform that lets you automate data manipulation tasks.
You specify the tasks using a visual graph notation known as a *workflow*. Each node in the
graph represents a task, and the edges represent the data flow between tasks.

The
[Redis vector store](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.vectorstoreredis/)
node lets you access [vector search]() capabilities from
your n8n workflows. Some typical usage patterns include:

-   **Use as a regular node to insert and retrieve documents**: Use the Redis Vector Store as a
    regular node to insert or get documents in the regular connection flow without using an agent.
-   **Connect directly to an AI agent as a tool**: Connect the Redis Vector Store node directly to
    the tool connector of an AI agent to use a vector store as a resource when answering queries.
-   **Use a retriever to fetch documents**: Use the
    [Vector Store Retriever](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.retrievervectorstore/)
    node with the Redis Vector Store node to fetch documents that match the given chat input, often used with
    the [Question and Answer Chain](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.chainretrievalqa/)
    node.
-   **Use the Vector Store Question Answer Tool to answer questions**: Use the Vector Store
    [Question Answer Tool](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.toolvectorstore/)
    to summarize results and answer questions from the Redis Vector Store node, rather than connecting it
    directly as a tool.

The vector store node is a [cluster node](https://docs.n8n.io/integrations/builtin/cluster-nodes/)
that is designed to work with one or more *sub-nodes*. These let you choose additional
functionality, such as an embedding model to calculate the embedding vectors used in the search.

The sections below summarize how you can use the Redis vector store node in n8n,
but see the [Redis vector store node documentation](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.vectorstoreredis/) (available from the n8n workflow editor)
for more information.

title: Prerequisites

text:
To use the Redis vector store node, you need a Redis server with Redis Search enabled.
See the [Redis Cloud quickstart guide]()
or the [Redis Open Source installation guide]()
to learn how to set up a suitable Redis server within minutes.

title: Available operations

text:
The Redis Vector Store node has four operation modes that determine what operations you can perform:

-   **Get Many**: Retrieve multiple documents from your vector database by providing a prompt. The prompt is
    embedded and used for similarity search, returning the most similar documents with their similarity scores.
    Useful for retrieving a list of similar documents to pass to an agent as additional context.
-   **Insert Documents**: Insert new documents into your vector database.
-   **Retrieve Documents (as Vector Store for Chain/Tool)**: Use with a
    [Vector Store Retriever](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.retrievervectorstore/)
    to retrieve documents from a vector database and provide them to the retriever connected to a chain.
    You must connect the node to a retriever node or root node in this mode.
-   **Retrieve Documents (as Tool for AI Agent)**: Use the vector store as a tool resource when answering
    queries. The agent uses the vector store when the vector store name and description match the question
    details.

title: Example workflows

role: example

text:
Redis provides two well-annotated example workflows to demonstrate how you can use the Redis vector
store node in n8n.

-   [**Chat with GitHub issues using OpenAI and Redis Vector Search**](https://n8n.io/workflows/10837-chat-with-github-issues-using-openai-and-redis-vector-search/):
    This workflow uses the Redis vector store node to implement a basic RAG pattern. The chat answers
    questions about GitHub issues from the list of issues in a repository.
-   [**Semantic caching**](https://n8n.io/workflows/10887-reduce-llm-costs-with-semantic-caching-using-redis-vector-store-and-huggingface/):
    This workflow implements a [semantic cache](https://redis.io/blog/what-is-semantic-caching/)
    that checks for previously answered questions before calling an LLM. This pattern can help
    reduce LLM costs by answering questions from cached results.


title: Nagios with Redis Software

title: Overview

text:
The Nagios plugin has been retired as of Redis Software version 7.2.4.

The Redis Software (RS) Nagios plugin enables you to monitor the status of RS related
objects and alerts. The RS alerts can be related to the cluster, nodes,
or databases.

The alerts that can be monitored via Nagios are the same alerts that can
be configured in the RS UI in the Settings \> Alerts page, or the
specific Database \> Configuration page.

All alert configurations (active / not active, setting thresholds, etc')
can only be done through the RS UI, they cannot be configured in Nagios.
Through Nagios you can only view the status and information of the
alerts.

The full list of alerts can be found in the plugin package itself (in
"/rlec_obj/rlec_services.cfg" file, more details below).

RS Nagios plugin support API password retrieval from Gnome keyring,
KWallet, Windows credential vault, Mac OS X Keychain, if present, or
otherwise Linux Secret Service compatible password store. With no
keyring service available, the password is saved with base64 encoding,
under the user home directory.

title: Configuring the Nagios plugin

role: configuration

text:
In order to configure the Nagios plugin you need to copy the files that
come with the package into your Nagios environment and place them in a
Nagios configuration directory. Or, alternatively you can copy parts of
the package configuration into your existing Nagios configuration.

If Keyring capabilities are needed to store the password, python keyring
package should be installed and used by following the below steps from
the operating system CLI on Nagios machine:

1. pip install keyring to install the package (See
    https://pip.pypa.io/en/stable/installing/ on how to install python
    pip if needed).
1. keyring set RS-Nagios \<RS user email\> to set the password.
    User email should be identical to the email used in Nagios
    configuration and the password should be set using the same user
    that run the Nagios server.

Then, you need to update the local parameters, such as hostnames,
addresses, and object IDs, to the values relevant for your
RS deployment.

Finally, you need to set the configuration for each node and database
you would like to monitor. More details below.

The RS Nagios package includes two components:

- The plugin itself - with suffix "rlec_nagios_plugin"
- Configuration files - with suffix "rlec_nagios_conf"

Below is the list of files included in these packages and instructions
regarding what updates need to be made to these flies.

Note : The instructions below assume you are running on Ubuntu, have a
clean Nagios installation, and the base Nagios directory is
"/usr/local/nagios/"

title: Step 1

text:
Copy the folder named "libexec" from the plugin folder and its contents
to "/usr/local/nagios/"

These files included in it are:

- check_rlec_alert
- check_rlec_node
- check_rlec_bdb
- email_stub
- rlecdigest.py

Note : The check_rlec_alert, check_rlec_node, check_rlec_bdb files
are the actual plugin implementation. You can run each of them with a
"h" switch in order to retrieve their documentation and their expected
parameters.

title: Step 2

text:
Add the following lines to your "nagios.cfg":

- cfg_dir=/usr/local/nagios/etc/rlec_obj
- cfg_dir=/usr/local/nagios/etc/rlec_local
- resource_file=/usr/local/nagios/etc/rlec_resource.cfg

title: Step 3

text:
Copy the configuration files along with their folders to
"/usr/local/nagios/etc" and make the required updates, as detailed
below.

1. Under the "/etc" folder:
    1. "rlec_resource.cfg "  holds global variables definitions for
        the user and password to use to connect to RS. You should update
        the variables to the relevant user and password for your
        deployment.
    1. "rlec_local " folder
    1. "rlec_obj" folder
1. Under the "/rlec_local" folder:
    1. "cluster.cfg "  holds configuration details at the cluster
        level. If you would like to monitor more than one cluster then
        you need to duplicate the two existing entries in the file for
        each cluster.
        1. The first "define host" section defines a variable for the
            IP address of the cluster that is used in other
            configuration files.
            1. Update the "address" to the Cluster Name (FQDN) as
                defined in DNS, or the IP address of one of the nodes in
                the cluster.
            1. If you are configuring more than one RS then when
                duplicating this section you should make sure:
                1. The "name" is unique.
        1. In the second "define host" section:
            1. The "host_name " in each entry must be unique.
            1. The "display_name" in each entry can be updated to a
                user-friendly name that are shown in Nagios UI.
    1. "contacts.cfg "  holds configuration details who to send emails
        to. It should be updated to values relevant for your deployment.
        If this file already exists in your existing Nagios environment
        then you should update it accordingly.
    1. "databases.cfg"  holds configuration details of the databases
        to monitor. The "define host" section should be duplicated for
        every database to monitor.
        1. "host_name" should be a unique value.
        1. "display_name " should be updated to a user-friendly name
            to show in the UI.
        1. "_RLECID " should be the database's internal ID that can
            be retrieved from
            [`rladmin status`]() command output.
    1. "nodes.cfg "  holds configuration details of the nodes in the
        cluster. The "define host" section should be duplicated for
        every node in the cluster.
        1. "host_name" should be a unique value.
        1. "display_name " should be updated to a user-friendly name
            to show in the UI.
        1. "address" should be updated to the DNS name mapped to the
            IP address of the node, or to the IP address itself.
        1. "_RLECID " should be the node's internal ID that can be
            retrieved
            from [`rladmin status`]() command output.
    1. Under the "/rlec_obj" folder:
        1. "rlec_cmd.cfg"  holds configuration details of how to
            activate the plugin. No need to make any updates to it.
        1. "rlec_groups.cfg" holds definitions of host groups. No need
            to make any updates to it.
        1. "rlec_services.cfg" holds definitions of all alerts that
            are monitored. No need to make any updates to it.
        1. "rlec_templates.cfg" holds general RS Nagios definitions.
            No need to make any updates to it.


title: New Relic with Redis Cloud

title: Overview

text:
[New Relic](https://newrelic.com/?customer-bypass=true) is used by organizations of all sizes and across a wide range of industries to
enable digital transformation and cloud migration, drive collaboration among development, operations, security and
business teams, accelerate time to market for applications, reduce time to problem resolution, secure applications and
infrastructure, understand user behavior, and track key business metrics.

The New Relic Integration for Redis Cloud uses Prometheus remote write functionality to connect Prometheus data
sources to New Relic. This integration enables Redis Cloud users to export metrics to New Relic for analysis,
and includes Redis-designed dashboards for use in monitoring Redis Cloud clusters.

This integration makes it possible to:
- Collect and display metrics not available in the admin console
- Set up automatic alerts for node or cluster events
- Display these metrics alongside data from other systems

title: Install Redis' New Relic Integration for Redis Cloud

text:
The New Relic Integration for Redis is based on a feature of the Prometheus data source. Prometheus can forward metrics on to
another destination using remote writes. This will require a Prometheus installation inside the same datacenter as the
Redis Cloud deployment.

If you have not already created a VPC between the Redis Cloud cluster and the network in which the machine hosting
Prometheus lives you should do so now. Please visit [VPC Peering](https://redis.io/docs/latest/operate/rc/security/vpc-peering/)
and follow the instructions for the cloud platform of your choice.

Finally, the Prometheus installation must be configured to pull metrics from Redis Cloud and write them to New Relic. There
are two sections, first the pull from Redis and second the write to New Relic.

Get metrics from Redis Cloud:

[code example]

Write them to New Relic:

[code example]

title: View metrics

text:
The Redis Cloud Integration for New Relic contains pre-defined dashboards to aid in monitoring your Redis Software deployment.

The following dashboards are currently available:

- Cluster: top-level statistics indicating the general health of the cluster
- Database: performance metrics at the database level
- Node
- Shard: low-level details of an individual shard
- Active-Active: replication and performance for geo-replicated clusters
- Proxy: network and command information regarding the proxy
- Proxy Threads: processor usage information regarding the proxy's component threads

title: Monitor metrics

text:
New Relic dashboards can be filtered using the text area. For example, when viewing a cluster dashboard it is possible to
filter the display to show data for only one cluster by typing 'cluster' in the text area and waiting for the system to
retrieve the relevant data before choosing one of the options in the 'cluster' section.

Certain types of data do not know the name of the database from which they were drawn. The dashboard should have a list
of database names and ids; use the id value when filtering input to the dashboard.

code:
- job_name: "redis-cloud"
    scrape_interval: 30s
    scrape_timeout: 30s
    metrics_path: /
    scheme: https
    tls_config:
      insecure_skip_verify: true
    static_configs:
      # The default Redis Cloud Prometheus port is 8070.
      # Replace REDIS_CLOUD_HOST with your cluster's hostname.
      - targets: ["REDIS_CLOUD_HOST:8070"]

code:
# Remote write configuration for New Relic.
# - Replace REDIS_CLOUD_SERVICE NAME with any name you'd like to use to refer to this data source.
# - Replace NEW_RELIC_BEARER_TOKEN with the token you generated on the New Relic Administration -> API Keys page.
remote_write:
- url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=REDIS_CLOUD_SERVICE_NAME
  authorization:
    credentials: NEW_RELIC_BEARER_TOKEN


title: New Relic with Redis Software

title: Overview

text:
[New Relic](https://newrelic.com/?customer-bypass=true) is used by organizations of all sizes and across a wide range of industries to
enable digital transformation and cloud migration, drive collaboration among development, operations, security and
business teams, accelerate time to market for applications, reduce time to problem resolution, secure applications and
infrastructure, understand user behavior, and track key business metrics.

The New Relic Integration for Redis Software uses Prometheus remote write functionality to connect Prometheus data
sources to New Relic. This integration enables Redis Software users to export metrics to New Relic for analysis,
and includes Redis-designed dashboards for use in monitoring Redis Software clusters.

This integration makes it possible to:
- Collect and display metrics not available in the admin console
- Set up automatic alerts for node or cluster events
- Display these metrics alongside data from other systems

title: Install Redis' New Relic Integration for Redis Software

text:
The New Relic Integration for Redis is based on a feature of the Prometheus data source. Prometheus can forward metrics on to
another destination using remote writes. The Prometheus installation must be configured to pull metrics from Redis
Enterprise and write them to New Relic. There are two sections, first the pull from Redis and second the write to New Relic.

Get metrics from Redis Software:

[code example]

Write them to New Relic:

[code example]

title: View metrics

text:
The Redis Software Integration for New Relic contains pre-defined dashboards to aid in monitoring your Redis Software deployment.

The following dashboards are currently available:

- Cluster: top-level statistics indicating the general health of the cluster
- Database: performance metrics at the database level
- Node
- Shard: low-level details of an individual shard
- Active-Active: replication and performance for geo-replicated clusters
- Proxy: network and command information regarding the proxy
- Proxy Threads: processor usage information regarding the proxy's component threads

title: Monitor metrics

code:
- job_name: "redis-enterprise"
    scrape_interval: 30s
    scrape_timeout: 30s
    metrics_path: /
    scheme: https
    tls_config:
      insecure_skip_verify: true
    static_configs:
      # The default Redis Software Prometheus port is 8070.
      # Replace REDIS_ENTERPRISE_HOST with your cluster's hostname.
      - targets: ["REDIS_ENTERPRISE_HOST:8070"]

code:
# Remote write configuration for New Relic.
# - Replace REDIS_ENTERPRISE_SERVICE NAME with any name you'd like to use to refer to this data source.
# - Replace NEW_RELIC_BEARER_TOKEN with the token you generated on the New Relic Administration -> API Keys page.
remote_write:
- url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=REDIS_ENTERPRISE_SERVICE_NAME
  authorization:
    credentials: NEW_RELIC_BEARER_TOKEN


title: Node.js client for Redis

summary: Learn how to build with Redis and Node.js

title: Content

text:
Connect your Node.js application to a Redis database using the node-redis client library.

Refer to the complete [Node.js guide]() to install, connect, and use node-redis.


title: C#/.NET client for Redis

summary: Learn how to build with Redis and C#/.NET

title: Overview

text: Connect your C#/.NET application to a Redis database using the NRedisStack client library.

title: Overview

text: NRedisStack is a comprehensive .NET client library for Redis that extends StackExchange.Redis with support for all Redis data structures and capabilities. It provides strongly-typed APIs for Redis data structures and advanced features, making it ideal for modern .NET applications.

title: Key Features

text:
- **Redis Stack (v7.4 and earlier) and Redis 8 support**: Native support for JSON, time series, and probabilistic data structures, and Redis Search.
- **Strongly Typed**: Type-safe APIs with full IntelliSense support in Visual Studio
- **Async/Await**: Native asynchronous programming support for high-performance applications
- **StackExchange.Redis Integration**: Built on the proven StackExchange.Redis foundation
- **Connection Multiplexing**: Efficient connection sharing across multiple operations
- **Cluster Support**: Full Redis Cluster support for distributed deployments
- **Pipeline Support**: Command batching for improved throughput
- **.NET Ecosystem**: Seamless integration with ASP.NET Core, Entity Framework, and other .NET technologies

title: Getting Started

text: Refer to the complete [C#/.NET guide]() to install, connect, and use NRedisStack.


title: PHP client for Redis

summary: Learn how to build with Redis and PHP

title: Overview

text: Predis is the recommended PHP client for Redis.

title: Overview

text: Predis is a flexible and feature-complete Redis client for PHP that supports Redis 2.0+ and provides a clean, object-oriented interface.

title: Key Features

text:
- **Pure PHP implementation**: easy Composer installation, framework integration
- **Full Redis Support**: Complete command coverage for all Redis features
- **Framework Integration**: Seamless integration with Laravel, Symfony, and other PHP frameworks
- **Connection Management**: Automatic connection pooling and reconnection handling
- **Flexible Configuration**: Customizable connection parameters and command options
- **Error Handling**: Comprehensive exception handling for robust applications
- **Async Support**: Non-blocking operations for high-throughput applications

title: Getting Started

text: Refer to the complete [Predis guide]() to install, connect, and use PHP Redis clients with detailed examples and framework integration guides.


title: Prometheus and Grafana with Redis Cloud

summary: Use Prometheus and Grafana to collect and visualize Redis Cloud metrics.

title: Overview

text:
You can use Prometheus and Grafana to collect and visualize your Redis Cloud metrics.

- [Prometheus](https://prometheus.io/) is an open source systems monitoring and alerting toolkit that can scrape metrics from different sources.
- [Grafana](https://grafana.com/) is an open source metrics visualization tool that can process Prometheus data.

Redis Cloud exposes its metrics through a Prometheus endpoint. You can configure your Prometheus server to scrape metrics from your Redis Cloud subscription on port 8070.

The Redis Cloud Prometheus endpoint is exposed on Redis Cloud's internal network. To access this network, enable [VPC peering](), [Private Service Connect](), [AWS Transit Gateway](), or [AWS PrivateLink](). Private connectivity options are only available with Redis Cloud Pro. You cannot use Prometheus and Grafana with Redis Cloud Essentials.

The Prometheus endpoint's metrics cover all databases within a subscription. Any database added to or removed from the subscription is reflected automatically.

For more information on how Prometheus communicates with Redis Software clusters, see [Prometheus integration with Redis Software]().

title: Quick start

text: You can quickly set up Prometheus and Grafana for testing using the Prometheus and Grafana Docker images.

title: Prerequisites

text:
1. Create a [Redis Cloud Pro database]().

1. Set up [VPC peering]().

1. Extract the Prometheus endpoint from the private endpoint to your database. The private endpoint is in the [Redis Cloud console](https://cloud.redis.io/) under the [Configuration tab]() of your database. The Prometheus endpoint is on port 8070 of the internal server.

    For example, if your private endpoint is:

    [code example]

    The Prometheus endpoint is:

    [code example]

1. Create an instance to run Prometheus and Grafana on the same cloud provider as your Redis Cloud subscription (for example, Amazon Web Services or Google Cloud). This instance must:
    - Exist in the same region as your Redis Cloud subscription.
    - Connect to the VPC subnet that is peered with your Redis Cloud subscription.
    - Allow outbound connections to port 8070, so that Prometheus can scrape the Redis Cloud server for data.
    - Allow inbound connections to port 9090 for Prometheus and port 3000 for Grafana.
    - Be located in one of the CIDR ranges of the RFC-1918 internal IP standard, which is comprised of three CIDR ranges:

        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16

        The Prometheus endpoint is subject to a whitelist according to this standard.

title: Set up Prometheus

text:
To get started with custom monitoring with Prometheus on Docker:

1. Create a directory on the Prometheus instance called `prometheus` and create a `prometheus.yml` file in that directory.

1. Add the following contents to `prometheus.yml`. Replace `<prometheus_endpoint>` with the Prometheus endpoint.

    [code example]

1. Create a `docker-compose.yml` file with instructions to set up the Prometheus and Grafana Docker images.

    [code example]

1. To start the containers, run:

    [code example]

1. To check that all the containers are up, run: `docker ps`
1. In your browser, sign in to Prometheus at `http://localhost:9090` to make sure the server is running.
1. Select **Status** and then **Targets** to check that Prometheus is collecting data from the Redis Cloud cluster.

    If Prometheus is connected to the cluster, you can type **node_up** in the Expression field on the Prometheus home page to see the cluster metrics.

See [Prometheus Metrics]() for a list of metrics that Prometheus collects from Redis Software clusters.

title: Set up Grafana

text:
Once the Prometheus and Grafana Docker containers are running, and Prometheus is connected to your Redis Cloud subscription, you can set up your Grafana dashboards.

1. Sign in to Grafana. If you installed Grafana with Docker, go to `http://localhost:3000` and sign in with:

    - Username: `admin`
    - Password: `secret`

1. In the Grafana configuration menu, select **Data Sources**.

1. Select **Add data source**.

1. Select **Prometheus** from the list of data source types.

1. Enter the Prometheus configuration information:

    - Name: `redis-cloud`
    - URL: `http://prometheus-server:9090`
    - Access: `Server`

- If the network port is not accessible to the Grafana server, select the **Browser** option from the Access menu.
- In a testing environment, you can select **Skip TLS verification**.

1. Add dashboards for your subscription and database metrics.
    To add preconfigured dashboards:
    1. In the Grafana dashboards menu, select **Manage**.
    1. Select **Import**.
    1. Add the [subscription status](https://grafana.com/grafana/dashboards/18406-subscription-status-dashboard/) and [database status](https://grafana.com/grafana/dashboards/18407-database-status-dashboard/) dashboards.

title: Grafana dashboards for Redis Cloud

text:
Redis publishes preconfigured dashboards for Redis Cloud and Grafana:

* The [subscription status dashboard](https://grafana.com/grafana/dashboards/18406-subscription-status-dashboard/) provides an overview of your Redis Cloud subscriptions.
* The [database status dashboard](https://grafana.com/grafana/dashboards/18407-database-status-dashboard/) displays specific database metrics, including latency, memory usage, ops/second, and key count.
* The [Active-Active dashboard](https://github.com/redis-field-engineering/redis-enterprise-observability/blob/main/grafana/dashboards/grafana_v9-11/cloud/basic/redis-cloud-active-active-dashboard_v9-11.json) displays metrics specific to [Active-Active databases]().

These dashboards are open source. For additional dashboard options, or to file an issue, see the [Redis Enterprise observability Github repository](https://github.com/redis-field-engineering/redis-enterprise-observability/tree/main/grafana).

For more information about configuring Grafana dashboards, see the [Grafana documentation](https://grafana.com/docs/).

section_id: prerequisites

code:
global:
        scrape_interval: 15s
        evaluation_interval: 15s

        # Attach these labels to any time series or alerts when communicating with
        # external systems (federation, remote storage, Alertmanager).
        external_labels:
            monitor: "prometheus-stack-monitor"

    # Load and evaluate rules in this file every 'evaluation_interval' seconds.
    #rule_files:
    # - "first.rules"
    # - "second.rules"

    scrape_configs:
        # scrape Prometheus itself
        - job_name: prometheus
        scrape_interval: 10s
        scrape_timeout: 5s
        static_configs:
          - targets: ["localhost:9090"]

        # scrape Redis Cloud
        - job_name: redis-cloud
        scrape_interval: 30s
        scrape_timeout: 30s
        metrics_path: /  # For v2, use /v2
        scheme: https
        static_configs:
          - targets: ["<prometheus_endpoint>:8070"]

section_id: set-up-prometheus

code:
version: '3'
    services:
        prometheus-server:
            image: prom/prometheus
            ports:
                - 9090:9090
            volumes:
                - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml

        grafana-ui:
            image: grafana/grafana
            ports:
                - 3000:3000
            environment:
                - GF_SECURITY_ADMIN_PASSWORD=secret
            links:
                - prometheus-server:prometheus

code: $ docker compose up -d


summary: Use Prometheus and Grafana to collect and visualize Redis Software metrics.

summary: Using monitoring and observability with Redis Software

title: Redis Software observability and monitoring guidance

summary: V1 metrics available to Prometheus.

title: Prometheus metrics v1

summary: Transition from v1 metrics to v2 PromQL equivalents.

title: Transition from Prometheus v1 to Prometheus v2

summary: V2 metrics available to Prometheus as of Redis Software version 7.8.2.

title: Prometheus metrics v2


title: Prometheus metrics v2

title: Content

text:
You can [integrate Redis Software with Prometheus and Grafana]() to create dashboards for important metrics.

The v2 metrics in the following tables are available as of Redis Software version 7.8.0. For help transitioning from v1 metrics to v2 PromQL, see [Prometheus v1 metrics and equivalent v2 PromQL]().

The v2 scraping endpoint also exposes metrics for `node_exporter` version 1.8.1. For more information, see the [Prometheus node_exporter GitHub repository](https://github.com/prometheus/node_exporter).


title: Prometheus metrics v1

summary: V1 metrics available to Prometheus.

title: Content

text:
You can [integrate Redis Software with Prometheus and Grafana]() to create dashboards for important metrics.

As of Redis Software version 7.8.2, v1 metrics are deprecated but still available. For help transitioning from v1 metrics to v2 PromQL, see [Prometheus v1 metrics and equivalent v2 PromQL]().


title: Content

text:
You can [integrate Redis Software with Prometheus and Grafana]() to create dashboards for important metrics.

As of Redis Software version 7.8.2, [PromQL (Prometheus Query Language)](https://prometheus.io/docs/prometheus/latest/querying/basics/) metrics are available. V1 metrics are deprecated but still available.

To transition from v1 metrics to v2 metrics, you need to change the `metrics_path` in your Prometheus configuration file from `/` to `/v2` to use the new scraping endpoint.

Here's an example of the updated scraping configuration in `prometheus.yml`:

[code example]

It is possible to scrape both v1 and v2 endpoints simultaneously during the transition period to prepare dashboards and ensure a smooth transition.

You can use the following tables to transition from v1 metrics to equivalent v2 PromQL. For a list of all available v2 PromQL metrics, see [Prometheus metrics v2]().

code:
scrape_configs:
  # Scrape Redis Software
  - job_name: redis-enterprise
    scrape_interval: 30s
    scrape_timeout: 30s
    metrics_path: /v2
    scheme: https
    tls_config:
      insecure_skip_verify: true
    static_configs:
      - targets: ["<cluster_name>:8070"]

section_id: content


title: Get started with Pulumi

summary: Shows how to install the Redis Cloud Pulumi provider and create a subscription.

title: Overview

text: Here, you'll learn how to use the [Redis Cloud Pulumi provider]() to create a Redis Cloud Pro subscription and a database using Python.

title: Prerequisites

text:
1. [Install Pulumi](https://www.pulumi.com/docs/install/) and [create a Pulumi account](https://app.pulumi.com/signin) if you do not have one already.

1. [Create a Redis Cloud account]() if you do not have one already.

1. [Enable the Redis Cloud API]().

1. Get your Redis Cloud [API keys]().

title: Install the Pulumi provider files

text:
1.  In your Python project, create an empty folder. From this folder, run `pulumi new rediscloud-python`.

1. Log into Pulumi using your [Pulumi access token](https://app.pulumi.com/account/tokens) if prompted.

1.  Enter a project name, description, and stack name.

1.  Enter your Redis Cloud access and secret keys.

1.  Enter the credit card type (Visa, Mastercard) on file with your Redis Cloud account.

1.  Enter the last four numbers of the card on file with your Redis Cloud account.

Once these steps are completed, the dependencies needed for the project will be installed and a Python virtual environment will be created.

title: Deploy resources with Pulumi

text:
The Pulumi Python project includes three main files:

- `pulumi.yaml` : A metadata file which is used to help configure the Python runtime environment.

- `pulumi.YOUR_PROJECT_NAME.yaml`: Contains the information related to the Cloud API access and secret key, credit card type and last 4 digits.

- `__main__.py`: A Pulumi template file that creates a Redis Cloud Pro subscription. Use this template file as a starting point to create the subscription with a cloud provider and define specifications for the database (this includes memory, throughput, Redis advanced capabilities, and other information).

To deploy the resources described in `__main__.py`, run `pulumi up`. This will take some time. You will be able to see your subscription being created through the [Redis Cloud console](https://cloud.redis.io/).

If you want to remove these resources, run `pulumi down`.

title: More info

text:
- [Redis Cloud Pulumi registry](https://www.pulumi.com/registry/packages/rediscloud/)
- [Pulumi documentation](https://www.pulumi.com/docs/)


title: Pulumi provider for Redis Cloud

summary: Explains how to use Pulumi to provision Redis Cloud infrastructure

title: Get started with Pulumi

title: Overview

text:
[Pulumi](https://www.pulumi.com/) is an automation tool that allows you to easily provision infrastructure as code. Pulumi allows developers to write infrastructure code using programming languages rather than using domain-specific languages.

With the [Redis Cloud Resource Provider](https://www.pulumi.com/registry/packages/rediscloud/), you can create Redis Cloud resources in a programming language. The Pulumi Redis Cloud Provider supports the following programming languages:

* TypeScript
* Python
* C#
* Java
* Go
* YAML

The Redis Cloud Pulumi provider is based on the [Redis Cloud Terraform provider]().

The Redis Cloud Pulumi Redis Cloud provider supports Redis Cloud Pro. It does not support Redis Cloud Essentials.

See [Get started with Pulumi]() for an example of how to use the Pulumi provider with Python.

title: Resources and functions

text:
Pulumi resources represent the fundamental units that make up cloud infrastructure. A provider can make functions available in its SDK and resource types. These functions are often used to acquire information that is not part of a resource.

The Redis Cloud Pulumi provider allows for the following resources:

* [`Subscription`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/subscription/): The basic building block of a Redis Cloud subscription.
* [`SubscriptionDatabase`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/subscriptiondatabase/): Represents a Redis database which belongs to a specific Redis Cloud subscription.
* [`SubscriptionPeering`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/subscriptionpeering/): A VPC peering connection (AWS or GCP) to a specific Redis Cloud subscription.
* [`CloudAccount`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/cloudaccount/): Represents an AWS account in which you want to deploy Redis Cloud infrastructure components.

The "bring your own AWS account" option for Redis Cloud has been deprecated. The `CloudAccount` resource is only available for legacy Redis Cloud integrations.

* [`ActiveActiveSubscription`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/activeactivesubscription/): The basic building block of an active-active Redis Cloud subscription.
* [`ActiveActiveSubscriptionDatabase`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/activeactivesubscriptiondatabase/): Represents a Redis database which belongs to a specific Redis Cloud active-active subscription.
* [`ActiveActiveSubscriptionRegions`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/activeactivesubscriptionregions/): The different regions where the active-active subscription will be deployed.
* [`ActiveActiveSubscriptionPeering`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/activeactivesubscriptionpeering/): A VPC peering connection (AWS or GCP) to a specific Redis Cloud active-active subscription.
* [`AclRule`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/aclrule/), [`AclRole`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/aclrole/), and [`AclUser`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/acluser/): Rules, Roles, and Users for [Role-based access control]().

It also allows for the following functions:

* [`GetCloudAccount`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getcloudaccount/): Get the information related to the AWS account.

The "bring your own AWS account" option for Redis Cloud has been deprecated. The `CloudAccount` resource is only available for legacy Redis Cloud integrations.

* [`GetDataPersistence`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getdatapersistence/): Get the type of database persistence.
* [`GetDatabase`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getdatabase/): Get the information related to a specific database.
* [`GetDatabaseModules`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getdatabasemodules/): Get the capabilities for a specific database.
* [`GetPaymentMethod`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getpaymentmethod/): Get the payment method related to the Redis Cloud account.
* [`GetRegions`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getregions/): Get the regions related to an active-active subscription
* [`GetSubscription`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getsubscription/): Get the information related to a specific subscription.
* [`GetSubscriptionPeerings`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getsubscriptionpeerings/): Get the VPC peerings (AWS or GCP) related to a specific subscription.
* [`GetAclRule`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getaclrule/), [`GetAclRole`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getaclrole/), and [`GetAclUser`](https://www.pulumi.com/registry/packages/rediscloud/api-docs/getacluser/): Get the Rules, Roles, and Users for [Role-based access control]().

title: More info

text:
- [Get started with Pulumi]()
- [Redis Cloud Pulumi registry](https://www.pulumi.com/registry/packages/rediscloud/)
- [Pulumi documentation](https://www.pulumi.com/docs/)


title: Redis on Railway

summary: Deploy and host Redis on Railway. The Railway Redis database template allows you to provision and connect to a Redis database with zero configuration.

title: Overview

text:
[Railway](https://railway.com?utm_medium=integration&utm_source=docs&utm_campaign=redis) simplifies your infrastructure stack from databases to servers to observability with a single, scalable, easy-to-use platform. Companies of all sizes deploy full-stack applications on Railway and benefit from highly performant networking, intuitive vertical and horizontal scaling, and isolated environments with pull request deploys. Railway's template marketplace includes thousands of one-click deploy templates, including Redis.

This is a guide to deploying Redis on Railway, using the official template.

title: Deploy Redis to Railway

text:
Navigate to a new Railway project at [railway.com/new](https://railway.com/new?utm_medium=integration&utm_source=docs&utm_campaign=redis). Add a Redis database to your project via the `ctrl / cmd + k` menu, and type `Redis`.

You can also deploy it via the [template](https://railway.com/deploy/redis) from the Railway template marketplace.

Upon deployment, you will have a Redis service running in your project, deployed from the [redis](https://hub.docker.com/_/redis) Docker image.

Since the deployed container is pulled from the [redis](https://hub.docker.com/_/redis) image in Docker Hub, you can modify the deployment based on the [instructions in Docker Hub](https://hub.docker.com/_/redis).

title: Connecting to your Railway Redis Service

text: It is possible to connect to Redis externally by using the [TCP Proxy](https://docs.railway.com/deploy/exposing-your-app#tcp-proxying?utm_medium=integration&utm_source=docs&utm_campaign=redis) which is enabled by default.

title: Backup and Monitoring

text:
Especially for production environments, performing backups and monitoring the health of your data is essential. Consider adding:

- **Backups**: Automate regular backups to ensure data recovery in case of failure. We suggest checking out Railway's native [Backups](https://docs.railway.com/reference/backups?utm_medium=integration&utm_source=docs&utm_campaign=redis) feature.

- **Observability**: Implement monitoring for insights into performance and health of your Redis cluster. You can integrate a Redis exporter for Prometheus, although we do not provide a specific template at this time.

title: Additional Resources

text:
- [Railway Redis guide](https://docs.railway.com/guides/redis?utm_medium=integration&utm_source=docs&utm_campaign=redis)
- [Railway platform features](https://railway.com/features?utm_medium=integration&utm_source=docs&utm_campaign=redis)


title: Redis for AI

summary: Build AI applications with Redis vector database and semantic caching

title: Overview

text: Build powerful AI applications using Redis as your vector database with specialized libraries for Python, JavaScript, and Java.

title: Overview

text:
Redis provides comprehensive AI libraries and tools to help you build intelligent applications with vector search, retrieval-augmented generation (RAG), semantic caching, and more. Whether you're working with LangChain, LlamaIndex, or building custom AI solutions, Redis has the tools you need.

[Explore the complete Redis for AI documentation]()

title: Key Features

text:
- **Vector Search**: Store and query vector embeddings with HNSW and FLAT index types
- **Semantic Caching**: Cache LLM responses to reduce costs and improve performance
- **RAG Support**: Build retrieval-augmented generation applications with popular frameworks
- **Multi-language Support**: Libraries available for Python, JavaScript, and Java
- **Real-time Performance**: Sub-millisecond query latency for production AI applications

title: AI Libraries

title: RedisVL (Python)

text:
The Redis Vector Library (RedisVL) is a Python client library for building AI applications with Redis.

- **Vector Search**: Create and query vector indexes with ease
- **Semantic Caching**: Built-in LLM cache for faster responses
- **RAG Utilities**: Tools for building retrieval-augmented generation apps
- **Framework Integration**: Works with LangChain, LlamaIndex, and more

[Learn more about RedisVL]()

title: LangChain Integration

text:
Use Redis with LangChain for vector stores, semantic caching, and chat message history.

- **Vector Store**: Store and retrieve embeddings for RAG applications
- **Semantic Cache**: Cache LLM responses based on semantic similarity
- **Chat History**: Persist conversation history for AI agents

[Learn more about LangChain integration]()

title: Client Libraries with Vector Search

text:
All major Redis client libraries support vector search operations:

- **redis-py (Python)**: [Vector search guide]()
- **node-redis (JavaScript)**: [Vector search guide]()
- **Jedis (Java)**: [Vector search guide]()
- **NRedisStack (C#/.NET)**: [Vector search guide]()
- **go-redis (Go)**: [Vector search guide]()

title: Getting Started

title: Quick Start Guides

text:
- [Redis vector database quick start]()
- [RAG quick start guide]()

title: Tutorials and Examples

text:
Explore our [AI notebooks collection]() with examples for:

- RAG implementations with RedisVL, LangChain, and LlamaIndex
- Advanced RAG techniques and optimizations
- Integration with cloud platforms like Azure and Vertex AI

title: Video Tutorials

text: Watch our [AI video collection]() for practical demonstrations.

title: Use Cases

text:
- **Retrieval-Augmented Generation (RAG)**: Enhance LLM responses with relevant context
- **Semantic Search**: Find similar documents, images, or products
- **Recommendation Systems**: Build real-time personalized recommendations
- **AI Agents**: Create autonomous agents with memory and tool use
- **Chatbots**: Build conversational AI with context and history

title: Additional Resources

text:
- [Complete AI documentation]()
- [Ecosystem integrations]()
- [Vector search benchmarks](https://redis.io/blog/benchmarking-results-for-vector-databases/)
- [RAG best practices](https://redis.io/blog/get-better-rag-responses-with-ragas/)


title: Architecture

summary: Discover the main components of RDI

title: Overview

text:
RDI implements a [change data capture](https://en.wikipedia.org/wiki/Change_data_capture) (CDC) pattern that tracks changes to the data in a
non-Redis *source* database and makes corresponding changes to a Redis
*target* database. You can use the target as a cache to improve performance
because it will typically handle read queries much faster than the source.

To use RDI, you define a *dataset* that specifies which data items
you want to capture from the source and how you want to
represent them in the target. For example, if the source is a
relational database then you specify which table columns you want
to capture but you don't need to store them in an equivalent table
structure in the target. This means you can choose whatever target
representation is most suitable for your app. To convert from the
source to the target representation, RDI applies *transformations*
to the data after capture.

RDI synchronizes the dataset between the source and target using
a *data pipeline* that implements several processing steps
in sequence:

1.  A *CDC collector* captures changes to the source database. RDI
    currently uses an open source collector called
    [Debezium](https://debezium.io/) for this step.

1.  The collector records the captured changes using
[Redis streams]()
    in the RDI database.

1.  A *stream processor* reads data from the streams and applies
    any transformations that you have defined (if you don't need
    any custom transformations then it uses defaults).
    It then writes the data to the target database for your app to use.

Note that the RDI control processes run on dedicated virtual machines (VMs)
outside the Redis
Enterprise cluster where the target database is kept. However, RDI keeps
its state and configuration data and also the change data streams in a Redis database on the same cluster as the target. The following diagram shows the pipeline steps and the path the data takes on its way from the source to the target:

When you first start RDI, the target database is empty and so all
of the data in the source database is essentially "change" data.
RDI collects this data in a phase called *initial cache loading*,
which can take minutes or hours to finish, depending on the size
of the source data. Once the initial cache loading is complete,
there is a *snapshot* dataset in the target that will gradually
change when new data gets captured from the source. At this point,
RDI automatically enters a second phase called *change streaming*, where
changes in the data are captured as they happen. Changes are usually
added to the target within a few seconds after capture.

title: At-least-once delivery guarantee

text:
RDI guarantees *at-least-once delivery* to the target. This means that
a given change will never be lost, but it might be added to the target
more than once. Apart from a slight performance overhead, adding a
change multiple times is harmless because the multiple writes
are [*idempotent*](https://en.wikipedia.org/wiki/Idempotence) (that is
to say that all writes after the first one make no change to the
overall state).

title: Checkpointing

text:
RDI uses Redis streams to store the sequence of change events
captured from the source. The events are then retrieved in order
from the streams, processed, and written to the target. The stream
processor uses a *checkpoint* mechanism to keep track of the last
event in the sequence that it has successfully processed and stored. If the processor fails
for any reason, it can restart from the last checkpoint and
re-process any events that might not have been written to the target.
This ensures that all changes are eventually recorded, even in the
face of failures.

title: Backpressure mechanism

text:
Sometimes, data records can get added to the streams faster than RDI can
process them. This can happen if the target is slowed or disconnected
or simply if the source quickly generates a lot of change data.
If this continues, then the streams will eventually occupy all the
available memory. When RDI detects this situation, it applies a
*backpressure* mechanism to slow or stop the flow of incoming data.
Change data is held at the source until RDI clears the backlog and has
enough free memory to resume streaming.

The Debezium log sometimes reports that RDI has run out
of memory (usually while creating the initial snapshot). This is not
an error, just an informative message to note that RDI has applied
the backpressure mechanism.

title: Supported sources

role: compatibility

text: RDI supports the following database sources using [Debezium Server](https://debezium.io/documentation/reference/stable/operations/debezium-server.html) connectors:

title: How RDI is deployed

text:
RDI is designed with three *planes* that provide its services.

The *control plane* contains the processes that keep RDI active.
It includes:

-   An *API server* process that exposes a REST API to observe and control RDI.
-   An *operator* process that manages the *data plane* processes.
-   A *metrics exporter* process that reads metrics from the RDI database
    and exports them as [Prometheus](https://prometheus.io/) metrics.

The *data plane* contains the processes that actually move the data.
It includes the *CDC collector* and the *stream processor* that implement
the two phases of the pipeline lifecycle (initial cache loading and change streaming).

The *management plane* provides tools that let you interact
with the control plane.

-   Use the CLI tool to install and administer RDI and to deploy
    and manage a pipeline.
-   Use the pipeline editor included in Redis Insight to design
    or edit a pipeline.

The diagram below shows all RDI components and the interactions between them:

The following sections describe the VM configurations you can use to
deploy RDI.

title: RDI on your own VMs

text:
For this deployment, you must provide two VMs. The collector and stream processor
are active on one VM, while on the other they are in standby to provide high availability.
The two operators running on both VMs use a leader election algorithm to decide which
VM is the active one (the "leader").
The diagram below shows this configuration:

See [Install on VMs]()
for more information.

title: RDI on Kubernetes

text:
You can use the RDI [Helm chart](https://helm.sh/docs/topics/charts/) to install
on [Kubernetes (K8s)](https://kubernetes.io/), including Red Hat
[OpenShift](https://docs.openshift.com/). This creates:

-   A K8s [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) named `rdi`.
    You can also use a different namespace name if you prefer.
-   [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) and
    [services](https://kubernetes.io/docs/concepts/services-networking/service/) for the
    [RDI operator](),
    [metrics exporter](), and API server.
-   A [service account](https://kubernetes.io/docs/concepts/security/service-accounts/)
    and [RBAC resources](https://kubernetes.io/docs/reference/access-authn-authz/rbac) for the RDI operator.
-   A [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) with RDI database details.
-   [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)
    with the RDI database credentials and TLS certificates.
-   Other optional K8s resources such as [ingresses](https://kubernetes.io/docs/concepts/services-networking/ingress/)
    that can be enabled depending on your K8s environment and needs.

See [Install on Kubernetes]()
for more information.

title: Secrets and security considerations

text:
The credentials for the database connections, as well as the certificates
for [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) and
[mTLS](https://en.wikipedia.org/wiki/Mutual_authentication#mTLS) are saved in K8s secrets.
RDI stores all state and configuration data inside the Redis Enterprise cluster
and does not store any other data on your RDI VMs or anywhere else outside the cluster.


title: Data denormalization

summary: Learn about denormalization strategies

title: Overview

text:
The data in the source database is often
[*normalized*](https://en.wikipedia.org/wiki/Database_normalization).
This means that columns can't have composite values (such as arrays) and relationships between entities
are expressed as mappings of primary keys to foreign keys between different tables.
Normalized data models reduce redundancy and improve data integrity for write queries but this comes
at the expense of speed.
A Redis cache, on the other hand, is focused on making *read* queries fast, so RDI provides data
*denormalization* to help with this.

title: Joining one-to-one relationships

text:
You can join one-to-one relationships by making more than one job to write to the same Redis key.

First, you must configure the parent entity to use `merge` as the `on_update` strategy.

[code example]

Then, you can configure the child entity to write to the same Redis key as the parent entity. You can do this by using the `key` attribute in the `with` block of the job, as shown in this example:

[code example]

The joined data will look like this in Redis:

[code example]

If you don't set `merge` as the `on_update` strategy for all jobs targeting the same key, the entire parent record in Redis will be overwritten whenever any related record in the source database is updated. This will result in the loss of values written by other jobs.

When using this approach, you must ensure that the `key` expression in the child job matches the key expression in the parent job. If you use a different key expression, the child data will not be written to the same Redis key as the parent data.

In the example above, the `addresses` job uses the default key pattern to write to the same Redis key as the `customers` job. You can find more information about the default key pattern [here]().

You can also use custom keys for the parent entity, as long as you use the same key for all jobs that write to the same Redis key.

title: Joining one-to-many relationships

text:
To join one-to-many relationships, you can use the *Nesting* strategy.
With this, the parent object (the "one") is represented as a JSON document with the children (the "many") nested inside it as a JSON map attribute. The diagram below shows a nesting with the child objects in a map called `InvoiceLineItems`:

To configure normalization, you must first configure the parent entity to use JSON as the target data type. Add `data_type: json` to the parent job as shown in the example below:

[code example]

After you have configured the parent entity, you can then configure the child entities to be nested under it, based on their relation type. To do this, use the `nest` block, as shown in this example:

[code example]

The job has a `with` section under `output` that includes the `nest` block.
The job must include the following attributes in the `nest` block:

- `parent`: This specifies the config of the parent entities. You only
  need to supply the parent `table` name. Note that this attribute refers to a Redis *key* that will be added to the target
  database, not to a table you can access from the pipeline. See [Using nesting](#using-nesting) below
  for the format of the key that is generated.
- `nesting_key`: The unique key of each child entry in the JSON map that will be created under the path.
- `parent_key`: The field in the parent entity that stores the unique ID (foreign key) of the parent entity. This can't be a composite key.
- `child_key`: The field in the child entity that stores the unique ID (foreign key) to the parent entity. You only need to add this attribute if the name of the child's foreign key field is different from the parent's. This can't be a composite key.
- `path`: The [JSONPath](https://goessner.net/articles/JsonPath/)
  for the map where you want to store the child entities. The path must start with the `$` character, which denotes
  the document root.
- `structure`: (Optional) The type of JSON nesting structure for the child entities. Currently, only a JSON map
  is supported so if you supply this attribute then the value must be `map`.

title: Using nesting

text:
There are several important things to note when you use nesting:

- When you specify `nest` in the job, you must also set the `data_type` attribute to `json` and
  the `on_update` attribute to `merge` in the surrounding `output` block.
- Key expressions are *not* supported for the `nest` output blocks. The parent key is always calculated
  using the following template:

  [code example]

  For example:

  [code example]

- If you specify `expire` in the `nest` output block then this will set the expiration on the *parent* object.
- You can only use one level of nesting.
- If you are using PostgreSQL then you must make the following change for all child tables that you want to nest:

  [code example]

  This configuration affects the information written to the write-ahead log (WAL) and whether it is available
  for RDI to capture. By default, PostgreSQL only records
  modified fields in the log, which means that it might omit the `parent_key`. This can cause incorrect updates to the
  Redis key in the destination database.
  See the
  [Debezium PostgreSQL Connector Documentation](https://debezium.io/documentation/reference/connectors/postgresql.html#postgresql-replica-identity)
  for more information about this.
- Prior to RDI v1.12.1, there is a known limitation if you change the foreign key of a child object. In that scenario, the child object will be added to the new parent, but the old parent will not be updated.

code:
# jobs/customers.yaml
source:
  table: customers

output:
  - uses: redis.write
    with:
      data_type: json
      on_update: merge

section_id: joining-one-to-one-relationships

code:
# jobs/addresses.yaml
source:
  table: addresses

transform:
  - uses: add_field
    with:
      field: customer_address
      language: jmespath
      # You can use the following JMESPath expression to create a JSON object and combine the address fields into a single object.
      expression: |
        {
          "street": street,
          "city": city,
          "state": state,
          "zip": zip
        }

output:
  - uses: redis.write
    with:
      data_type: json
      # We specify the key to write to the same key as the parent entity.
      key:
        expression: concat(['customers:id:', customer_id])
        language: jmespath
      on_update: merge
      mapping:
        # You can specify one or more fields to write to the parent entity.
        - customer_address: customer_address

first_name: John

last_name: Doe

street: 123 Main St

city: Anytown

state: CA

code:
# jobs/invoice.yaml
source:
  schema: public
  table: Invoice

output:
  - uses: redis.write
    with:
      # Setting the data type to json ensures that the parent object will be created in a way that supports nesting.
      data_type: json
      # Important: do not set a custom key for the parent entity.
      # When nesting the child object under the parent, the parent key is automatically calculated based on
      # the parent table name and the parent key field and if a custom key is set, it will cause a mismatch
      # between the key used to write the parent and the key used to write the child.

section_id: joining-one-to-many-relationships

code:
# jobs/invoice_line.yaml
source:
  schema: public
  table: InvoiceLine
output:
  - uses: redis.write
    with:
      nest: # cannot co-exist with other parameters such as 'key'
        parent:
          # schema: public
          table: Invoice
        nesting_key: InvoiceLineId # the unique key in the composite structure under which the child data will be stored
        parent_key: InvoiceId
        child_key: InvoiceId # optional, if different from parent_key
        path: $.InvoiceLineItems # path must start from document root ($)
        structure: map # only map supported for now
      on_update: merge # only merge supported for now
      data_type: json # only json supported for now

section_id: using-nesting

code: ALTER TABLE <TABLE_NAME> REPLICA IDENTITY FULL;


title: Deploy a pipeline

summary: Learn how to deploy an RDI pipeline

title: Overview

text:
The sections below explain how to deploy a pipeline after you have created the required
[configuration]().

title: Set secrets

text:
Before you deploy your pipeline, you must set the authentication secrets for the
source and target databases. Each secret has a name that you can pass to the
[`redis-di set-secret`]()
command (VM deployment) or the `rdi-secret.sh` script (K8s deployment) to set the secret value.
You can then refer to these secrets in the `config.yaml` file using the syntax "`${SECRET_NAME}`"
(the sample
[config.yaml file]()
shows these secrets in use).

The table below lists all valid secret names. Note that the
username and password are required for the source and target, but the other
secrets are only relevant for TLS/mTLS connections.

| Secret name | Description |
| :-- | :-- |
| `SOURCE_DB_USERNAME` | Username for the source database |
| `SOURCE_DB_PASSWORD` | Password for the source database |
| `SOURCE_DB_CACERT` | (For TLS only) Source database CA certificate |
| `SOURCE_DB_CERT` | (For mTLS only) Source database client certificate |
| `SOURCE_DB_KEY` | (For mTLS only) Source database private key |
| `SOURCE_DB_KEY_PASSWORD` | (For mTLS only) Source database private key password |
| `TARGET_DB_USERNAME` | Username for the target database |
| `TARGET_DB_PASSWORD` | Password for the target database |
| `TARGET_DB_CACERT` | (For TLS only) Target database CA certificate |
| `TARGET_DB_CERT` | (For mTLS only) Target database client certificate |
| `TARGET_DB_KEY` | (For mTLS only) Target database private key |
| `TARGET_DB_KEY_PASSWORD` | (For mTLS only) Target database private key password |

title: Set secrets for VM deployment

text:
Use [`redis-di set-secret`]()
to set secrets for a VM deployment.

The specific command lines for source secrets are as follows:

[code example]

The corresponding command lines for target secrets are:

[code example]

title: Set secrets for K8s/Helm deployment using the rdi-secret.sh script

text:
Use the `rdi-secret.sh` script to set secrets for a K8s/Helm deployment. To use this script, unzip the archive that contains the RDI Helm chart and navigate to the resulting folder. The `rdi-secret.sh` script is located in the `scripts` subfolder. The general pattern for using this script is:

[code example]

The script also lets you retrieve a specific secret or list all the secrets that have been set:

[code example]

The specific command lines for source secrets are as follows:

[code example]

The corresponding command lines for target secrets are:

[code example]

title: Set secrets for K8s/Helm deployment using Kubectl command

text:
In some scenarios, you may prefer to use [`kubectl create secret generic`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_create/kubectl_create_secret_generic/)
to set secrets for a K8s/Helm deployment. The general pattern of the commands is:

[code example]

Where `<DB>` is either `source-db` for source secrets or `target-db` for target secrets.

If you use TLS or mTLS for either the source or target databases, you also need to create the `source-db-ssl` and/or `target-db-ssl` K8s secrets that contain the certificates used to establish secure connections. The general pattern of the commands is:

[code example]

The specific command lines for source secrets are as follows:

[code example]

The corresponding command lines for target secrets are:

[code example]

Note that the certificate paths contained in the secrets `SOURCE_DB_CACERT`, `SOURCE_DB_CERT`, and `SOURCE_DB_KEY` (for the source database) and `TARGET_DB_CACERT`, `TARGET_DB_CERT`, and `TARGET_DB_KEY` (for the target database) are internal to RDI, so you *must* use the values shown in the example above. You should only change the certificate paths when you create the `source-db-ssl` and `target-db-ssl` secrets.

title: Deploy a pipeline

text:
When you have created your configuration, including the [jobs](), you are
ready to deploy. Use [Redis Insight]()
to configure and deploy pipelines for both VM and K8s installations.

For VM installations, you can also use the
[`redis-di deploy`]()
command to deploy a pipeline:

[code example]

code:
# For username and password
redis-di set-secret SOURCE_DB_USERNAME yourUsername
redis-di set-secret SOURCE_DB_PASSWORD yourPassword

# With source TLS, in addition to the above
redis-di set-secret SOURCE_DB_CACERT /path/to/myca.crt

# With source mTLS, in addition to the above
redis-di set-secret SOURCE_DB_CERT /path/to/myclient.crt
redis-di set-secret SOURCE_DB_KEY /path/to/myclient.key
# Use this only if SOURCE_DB_KEY is password-protected
redis-di set-secret SOURCE_DB_KEY_PASSWORD yourKeyPassword

section_id: set-secrets-for-vm-deployment

code:
# For username and password
redis-di set-secret TARGET_DB_USERNAME yourUsername
redis-di set-secret TARGET_DB_PASSWORD yourPassword

# With target TLS, in addition to the above
redis-di set-secret TARGET_DB_CACERT /path/to/myca.crt

# With target mTLS, in addition to the above
redis-di set-secret TARGET_DB_CERT /path/to/myclient.crt
redis-di set-secret TARGET_DB_KEY /path/to/myclient.key
# Use this only if TARGET_DB_KEY is password-protected
redis-di set-secret TARGET_DB_KEY_PASSWORD yourKeyPassword

code: scripts/rdi-secret.sh set <SECRET-NAME> <SECRET-VALUE>

code:
# Get specific secret
scripts/rdi-secret.sh get <SECRET-NAME>

# List all secrets
scripts/rdi-secret.sh list

code:
# For username and password
scripts/rdi-secret.sh set SOURCE_DB_USERNAME yourUsername
scripts/rdi-secret.sh set SOURCE_DB_PASSWORD yourPassword

# With source TLS, in addition to the above
scripts/rdi-secret.sh set SOURCE_DB_CACERT /path/to/myca.crt

# With source mTLS, in addition to the above
scripts/rdi-secret.sh set SOURCE_DB_CERT /path/to/myclient.crt
scripts/rdi-secret.sh set SOURCE_DB_KEY /path/to/myclient.key
# Use this only if SOURCE_DB_KEY is password-protected
scripts/rdi-secret.sh set SOURCE_DB_KEY_PASSWORD yourKeyPassword

code:
# For username and password
scripts/rdi-secret.sh set TARGET_DB_USERNAME yourUsername
scripts/rdi-secret.sh set TARGET_DB_PASSWORD yourPassword

# With target TLS, in addition to the above
scripts/rdi-secret.sh set TARGET_DB_CACERT /path/to/myca.crt

# With target mTLS, in addition to the above
scripts/rdi-secret.sh set TARGET_DB_CERT /path/to/myclient.crt
scripts/rdi-secret.sh set TARGET_DB_KEY /path/to/myclient.key
# Use this only if TARGET_DB_KEY is password-protected
scripts/rdi-secret.sh set TARGET_DB_KEY_PASSWORD yourKeyPassword

code:
kubectl create secret generic <DB> \
--namespace=rdi \
--from-literal=<SECRET-NAME>=<SECRET-VALUE>

code:
kubectl create secret generic <DB>-ssl \
--namespace=rdi \
--from-file=<FILE-NAME>=<FILE-PATH>

code:
# Without source TLS
# Create or update source-db secret
kubectl create secret generic source-db --namespace=rdi \
--from-literal=SOURCE_DB_USERNAME=yourUsername \
--from-literal=SOURCE_DB_PASSWORD=yourPassword \
--save-config --dry-run=client -o yaml | kubectl apply -f -

# With source TLS
# Create of update source-db secret
kubectl create secret generic source-db --namespace=rdi \
--from-literal=SOURCE_DB_USERNAME=yourUsername \
--from-literal=SOURCE_DB_PASSWORD=yourPassword \
--from-literal=SOURCE_DB_CACERT=/etc/certificates/source_db/ca.crt \
--save-config --dry-run=client -o yaml | kubectl apply -f -
# Create or update source-db-ssl secret
kubectl create secret generic source-db-ssl --namespace=rdi \
--from-file=ca.crt=/path/to/myca.crt \
--save-config --dry-run=client -o yaml | kubectl apply -f -

# With source mTLS
# Create or update source-db secret
kubectl create secret generic source-db --namespace=rdi \
--from-literal=SOURCE_DB_USERNAME=yourUsername \
--from-literal=SOURCE_DB_PASSWORD=yourPassword \
--from-literal=SOURCE_DB_CACERT=/etc/certificates/source_db/ca.crt \
--from-literal=SOURCE_DB_CERT=/etc/certificates/source_db/client.crt \
--from-literal=SOURCE_DB_KEY=/etc/certificates/source_db/client.key \
--from-literal=SOURCE_DB_KEY_PASSWORD=yourKeyPassword \ # add this only if SOURCE_DB_KEY is password-protected
--save-config --dry-run=client -o yaml | kubectl apply -f -
# Create or update source-db-ssl secret
kubectl create secret generic source-db-ssl --namespace=rdi \
--from-file=ca.crt=/path/to/myca.crt \
--from-file=client.crt=/path/to/myclient.crt \
--from-file=client.key=/path/to/myclient.key \
--save-config --dry-run=client -o yaml | kubectl apply -f -

code:
# Without target TLS
# Create or update target-db secret
kubectl create secret generic target-db --namespace=rdi \
--from-literal=TARGET_DB_USERNAME=yourUsername \
--from-literal=TARGET_DB_PASSWORD=yourPassword \
--save-config --dry-run=client -o yaml | kubectl apply -f -

# With target TLS
# Create of update target-db secret
kubectl create secret generic target-db --namespace=rdi \
--from-literal=TARGET_DB_USERNAME=yourUsername \
--from-literal=TARGET_DB_PASSWORD=yourPassword \
--from-literal=TARGET_DB_CACERT=/etc/certificates/target_db/ca.crt \
--save-config --dry-run=client -o yaml | kubectl apply -f -
# Create or update target-db-ssl secret
kubectl create secret generic target-db-ssl --namespace=rdi \
--from-file=ca.crt=/path/to/myca.crt \
--save-config --dry-run=client -o yaml | kubectl apply -f -

# With target mTLS
# Create or update target-db secret
kubectl create secret generic target-db --namespace=rdi \
--from-literal=TARGET_DB_USERNAME=yourUsername \
--from-literal=TARGET_DB_PASSWORD=yourPassword \
--from-literal=TARGET_DB_CACERT=/etc/certificates/target_db/ca.crt \
--from-literal=TARGET_DB_CERT=/etc/certificates/target_db/client.crt \
--from-literal=TARGET_DB_KEY=/etc/certificates/target_db/client.key \
--from-literal=TARGET_DB_KEY_PASSWORD=yourKeyPassword \ # add this only if TARGET_DB_KEY is password-protected
--save-config --dry-run=client -o yaml | kubectl apply -f -
# Create or update target-db-ssl secret
kubectl create secret generic target-db-ssl --namespace=rdi \
--from-file=ca.crt=/path/to/myca.crt \
--from-file=client.crt=/path/to/myclient.crt \
--from-file=client.key=/path/to/myclient.key \
--save-config --dry-run=client -o yaml | kubectl apply -f -

code: redis-di deploy --dir <path to pipeline folder>

section_id: deploy-a-pipeline


title: Data pipelines

summary: Learn how to configure RDI for data capture and transformation.

summary: Enable CDC features in your source databases

title: Prepare source databases

summary: Learn how to specify the main configuration details for an RDI pipeline.

title: Pipeline configuration file

summary: Learn how to configure job files for data transformation.

title: Job files

summary: Learn about denormalization strategies

title: Data denormalization

summary: Learn how to deploy an RDI pipeline

title: Deploy a pipeline

title: Overview

text:
RDI uses *pipelines* to implement
[change data capture](https://en.wikipedia.org/wiki/Change_data_capture) (CDC). (See the
[architecture overview]()
for an introduction to pipelines.)
The sections below explain how pipelines work and give an overview of how to configure and
deploy them.

title: How a pipeline works

text:
An RDI pipeline captures change data records from the source database, and transforms them
into Redis data structures. It writes each of these new structures to a Redis target
database under its own key.

By default, RDI transforms the source data into
[hashes]() or
[JSON objects]() for the target with a
standard data mapping and a standard format for the key.
However, you can also provide your own custom transformation [jobs](#job-files)
for each source table, using your own data mapping and key pattern. You specify these
jobs declaratively with YAML configuration files that require no coding.

Data transformation involves two stages:

1.  The data ingested during CDC is automatically transformed to an intermediate JSON
    change event format.
1.  RDI passes this JSON change event data to your custom transformation for further
    processing.

The diagram below shows the flow of data through the pipeline:

You can provide a job file for each source table that needs a custom
transformation. You can also add a *default job file* for any tables that don't have their own.
You must specify the full name of the source table in the job file (or the special
name "*" in the default job) and you
can also include filtering logic to skip data that matches a particular condition.
As part of the transformation, you can specify any of the following data types
to store the data in Redis:

- [JSON]()
- [Hashes]()
- [Sets]()
- [Streams]()
- [Sorted sets]()
- [Strings]()

title: Pipeline lifecycle

text:
After you deploy a pipeline, it goes through the following phases:

1. *Deploy* - when you deploy the pipeline, RDI first validates it before use.
Then, the [operator]() creates and configures the collector and stream processor that will run the pipeline.
1. *Snapshot* - The collector starts the pipeline by creating a snapshot of the full
dataset. This involves reading all the relevant source data, transforming it and then
writing it into the Redis target. This phase typically takes minutes to
hours if you have a lot of data.
1. *CDC* - Once the snapshot is complete, the collector starts listening for updates to
the source data. Whenever a change is committed to the source, the collector captures
it and adds it to the target through the pipeline. This phase continues indefinitely
unless you change the pipeline configuration.
1. *Update* - If you update the pipeline configuration, the operator applies it
to the collector and the stream processor. Note that the changes only affect newly-captured
data unless you reset the pipeline completely. Once RDI has accepted the updates, the
pipeline returns to the CDC phase with the new configuration.
1. *Reset* - There are circumstances where you might want to rebuild the dataset
completely. For example, you might want to apply a new transformation to all the source
data or refresh the dataset if RDI is disconnected from the
source for a long time. In situations like these, you can *reset* the pipeline back
to the snapshot phase. When this is complete, the pipeline continues with CDC as usual.

title: Using a pipeline

text: Follow the steps described in the sections below to prepare and run an RDI pipeline.

title: 1. Prepare the source database

text:
Before using the pipeline you must first prepare your source database to use
the Debezium connector for *change data capture (CDC)*. See the
[architecture overview]()
for more information about CDC.
Each database type has a different set of preparation steps. You can
find the preparation guides for the databases that RDI supports in the
[Prepare source databases]()
section.

title: 2. Configure the pipeline

text:
RDI uses a set of [YAML](https://en.wikipedia.org/wiki/YAML)
files to configure each pipeline. The folder structure of the
configuration is shown below:

[code example]

The main configuration for the pipeline is in the `config.yaml` file.
This specifies the connection details for the source database (such
as host, username, and password) and also the queries that RDI will use
to extract the required data. You should place job files in the `Jobs`
folder if you want to specify your own data transformations.

See
[Pipeline configuration file]()
for a full description of the `config.yaml` file and some example configurations.

title: 3. Create job files (optional)

text:
You can use one or more job files to configure which fields from the source tables
you want to use, and which data structure you want to write to the target. You
can also optionally specify a transformation to apply to the data before writing it
to the target. See the
[Job files]()
section for full details of the file format and examples of common tasks for job files.

title: 4. Deploy the pipeline

text:
When your configuration is ready, you must deploy it to start using the pipeline. See
[Deploy a pipeline]()
to learn how to do this.

title: More information

text: See the other pages in this section for more information and examples:

code:
"(root)":
    "config.yaml":
        _meta:
            description: "\"config.yaml\" is the main pipeline configuration file."
    "jobs":
        _meta:
            description: "The 'jobs' folder containing optional job files."
        "default-job.yaml":
            _meta:
                description: "A default job."
        "job1.yaml":
          _meta:
                description: "Each job file must have a unique name."
        "...":
            _meta:
                ellipsis: true
                description: "Other job files, if required."