Docs Self-Managed Manage Kubernetes Remote Read Replicas This is documentation for Self-Managed v23.3. To view the latest available version of the docs, see v24.2. Remote Read Replicas in Kubernetes This feature requires an Enterprise license. To upgrade, contact Redpanda sales. A Remote Read Replica topic is a read-only topic that mirrors a topic on a different cluster. Remote Read Replicas work with both Tiered Storage and archival storage. When a topic has object storage enabled, you can create a separate remote cluster just for consumers of this topic, and populate its topics from remote storage. A read-only topic on a remote cluster can serve any consumer, without increasing the load on the origin cluster. Use cases for Remote Read Replicas include data analytics, offline model training, and development clusters. You can create Remote Read Replica topics in a Redpanda cluster that directly accesses data stored in cloud object storage. Because these read-only topics access data directly from cloud object storage instead of the topics' origin cluster, there’s no impact to the performance of the cluster. Topic data can be consumed within a region of your choice, regardless of the region where it was produced. The Remote Read Replica cluster must run on the same version of Redpanda as the origin cluster, or just one feature release ahead of the origin cluster. For example, if the origin cluster is version 23.1, the Remote Read Replica cluster can be 23.2, but not 23.4. It cannot skip feature releases. When upgrading, upgrade the Remote Read Replica cluster before upgrading the origin cluster. When upgrading to Redpanda 23.2, metadata from object storage is not synchronized until all brokers in the cluster are upgraded. If you need to force a mixed-version cluster to sync read replicas, move partition leadership to brokers running the original version. To create a Remote Read Replica topic in another region, consider using a multi-region bucket to simplify deployment and optimize performance. For default values and documentation for configuration options, see the values.yaml file. Prerequisites You need the following: An origin cluster with Tiered Storage set up. A topic on the origin cluster, which you can use as a Remote Read Replica topic on the remote cluster. A separate remote cluster in the same region as the bucket or container used for the origin cluster. If you use a multi-region bucket/container, you can create the read replica cluster in any region that has that bucket/container. If you use a single-region bucket/container, the remote cluster must be in the same region as the bucket/container. This feature requires an Enterprise license. To upgrade, contact Redpanda sales. To check if you already have a license key applied to your cluster: rpk cluster license info Configure object storage for the remote cluster You must configure access to the same object storage as the origin cluster. Amazon S3 Google Cloud Storage Azure Blob Storage You can configure access to Amazon S3 with either an IAM role attached to the instance or with access keys. To configure access to an S3 bucket with an IAM role: Configure an IAM role with read permissions for the S3 bucket. Override the following required cluster properties in the Helm chart: --values --set cloud-storage.yaml storage: tieredConfig: cloud_storage_enabled: true cloud_storage_credentials_source: aws_instance_metadata cloud_storage_region: <region> cloud_storage_bucket: "none" helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --values cloud-storage.yaml helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --set storage.tieredConfig.cloud_storage_enabled=true \ --set storage.tieredConfig.cloud_storage_credentials_source=aws_instance_metadata \ --set storage.tieredConfig.cloud_storage_region=<region> \ --set storage.tieredConfig.cloud_storage_bucket="none" Replace the following placeholders: <region>: The region of your S3 bucket. To configure access to an S3 bucket with access keys instead of an IAM role: Grant a user the following permissions to read objects on the bucket to be used with the cluster (or on all buckets): GetObject ListBucket Copy the access key and secret key for the cloud_storage_access_key and cloud_storage_secret_key cluster properties. Override the following required cluster properties in the Helm chart: --values --set cloud-storage.yaml storage: tieredConfig: cloud_storage_enabled: true cloud_storage_credentials_source: config_file cloud_storage_access_key: <access-key> cloud_storage_secret_key: <secret-key> cloud_storage_region: <region> cloud_storage_bucket: "none" helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --values cloud-storage.yaml helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --set storage.tieredConfig.cloud_storage_enabled=true \ --set storage.tieredConfig.cloud_storage_credentials_source=config_file \ --set storage.tieredConfig.cloud_storage_access_key=<access-key> \ --set storage.tieredConfig.cloud_storage_secret_key=<secret-key> \ --set storage.tieredConfig.cloud_storage_region=<region> \ --set storage.tieredConfig.cloud_storage_bucket="none" Replace the following placeholders: <access-key>: The access key for your S3 bucket. <secret-key>: The secret key for your S3 bucket. <region>: The region of your S3 bucket. You can configure access to Google Cloud Storage with either an IAM role attached to the instance or with access keys. To configure access to Google Cloud Storage with an IAM role, override the following required cluster properties in the Helm chart: --values --set cloud-storage.yaml storage: tieredConfig: cloud_storage_enabled: true cloud_storage_credentials_source: gcp_instance_metadata cloud_storage_region: <region> cloud_storage_bucket: "none" helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --values cloud-storage.yaml helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --set storage.tieredConfig.cloud_storage_enabled=true \ --set storage.tieredConfig.cloud_storage_credentials_source=aws_instance_metadata \ --set storage.tieredConfig.cloud_storage_region=<region> \ --set storage.tieredConfig.cloud_storage_bucket="none" Replace <region> with the region of your bucket. To configure access to Google Cloud Storage with access keys instead of an IAM role, override the following required cluster properties in the Helm chart: --values --set cloud-storage.yaml storage: tieredConfig: cloud_storage_enabled: true cloud_storage_credentials_source: config_file cloud_storage_api_endpoint: storage.googleapis.com cloud_storage_access_key: <access-key> cloud_storage_secret_key: <secret-key> cloud_storage_region: <region> cloud_storage_bucket: "none" helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --values cloud-storage.yaml helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --set storage.tieredConfig.cloud_storage_enabled=true \ --set storage.tieredConfig.cloud_storage_credentials_source=config_file \ --set storage.tieredConfig.cloud_storage_api_endpoint=storage.googleapis.com \ --set storage.tieredConfig.cloud_storage_access_key=<access-key> \ --set storage.tieredConfig.cloud_storage_secret_key=<secret-key> \ --set storage.tieredConfig.cloud_storage_region=<region> \ --set storage.tieredConfig.cloud_storage_bucket="none" Replace the following placeholders: <access-key>: The access key for your bucket. <secret-key>: The secret key for your bucket. <region>: The region of your bucket. To configure access to Azure Blob Storage, override the following required cluster properties in the Helm chart: Replace the following placeholders: --values --set cloud-storage.yaml storage: tieredConfig: cloud_storage_enabled: true cloud_storage_azure_shared_key: <access_key> cloud_storage_azure_storage_account: <account-name> cloud_storage_azure_container: "none" helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --values cloud-storage.yaml helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --create-namespace \ --set storage.tieredConfig.cloud_storage_enabled=true \ --set storage.tieredConfig.cloud_storage_azure_shared_key=<access_key> \ --set storage.tieredConfig.cloud_storage_azure_storage_account=<account-name> \ --set storage.tieredConfig.cloud_storage_azure_container="none" Replace the following placeholders: <access-key>: The access key for your Azure account. <account-name>: The name of your Azure account. Create a Remote Read Replica topic To create the Remote Read Replica topic, run: rpk topic create <topic_name> -c redpanda.remote.readreplica=<bucket_name> For <topic_name>, use the same name as the original topic. For <bucket_name>, use the bucket/container specified in the cloud_storage_bucket or cloud_storage_azure_container properties for the origin cluster. The Remote Read Replica cluster must run on the same version of Redpanda as the origin cluster, or just one feature release ahead of the origin cluster. For example, if the origin cluster is version 23.1, the Remote Read Replica cluster can be 23.2, but not 23.4. It cannot skip feature releases. During upgrades, upgrade the Remote Read Replica cluster before upgrading the origin cluster. Do not use redpanda.remote.read or redpanda.remote.write with redpanda.remote.readreplica. Redpanda ignores the values for remote read and remote write properties on read replica topics. Reduce lag in data availability When object storage is enabled on a topic, Redpanda copies closed log segments to the configured object store. Log segments are closed when the value of the segment size has been reached. A topic’s object store thus lags behind the local copy by the log_segment_size or, if set, by the topic’s segment.bytes value. To reduce this lag in the data availability for the Remote Read Replica: You can lower the value of segment.bytes. This lets Redpanda archive smaller log segments more frequently, at the cost of increasing I/O and file count. Self-Hosted implementations can set an idle timeout with storage.tiered.config.cloud_storage_segment_max_upload_interval_sec to force Redpanda to periodically archive the contents of open log segments to object storage. This is useful if a topic’s write rate is low and log segments are kept open for long periods of time. The appropriate interval may depend on your total partition count: a system with less partitions can handle a higher number of segments per partition. Suggested reading Remote Read Replicas: Read-only topics in Tiered Storage Back to top × Simple online edits For simple changes, such as fixing a typo, you can edit the content directly on GitHub. Edit on GitHub Or, open an issue to let us know about something that you want us to change. Open an issue Contribution guide For extensive content updates, or if you prefer to work locally, read our contribution guide . Was this helpful? thumb_up thumb_down group Ask in the community mail Share your feedback group_add Make a contribution Rack Awareness Manage Pod Resources