new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Temporal · all subjects

high availability

15 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Replica region must be on same continent as primary

When adding a replica for High Availability, the replica region must be on the same continent as the primary region. Not all replication options are available in all Temporal Cloud regions.

Adding a replica triggers automatic namespace failover

When you add a replica to a Namespace, it automatically fails the Namespace over. Workers must be planned to fail over with the replica; see Worker deployment patterns for high availability and disaster recovery.

Create Namespace with HA using tcld

To create a new Namespace with High Availability features using tcld, run: tcld namespace create --namespace <namespace_id>.<account_id> --region <primary_region> --region <replica_region>. Specify region codes as arguments to the two --region flags. If using API key authentication with --api-key flag, add it directly after tcld command and before namespace create.

Add HA to existing Namespace using tcld

To add High Availability to an existing Namespace using tcld, run: tcld namespace add-region --namespace <namespace_id>.<account_id> --region <replica_region>. Specify the region name (for example, us-east-1) as an argument to the --region flag. If using API key authentication with --api-key flag, add it directly after tcld command and before namespace add-region.

Cannot directly change replica location

Temporal Cloud cannot change replica locations directly. To change a replica's location, you must remove the replica and add a new one.

Seven-day waiting period after removing replica

After removing a replica from a region, you must wait seven days before you can re-enable High Availability in that same location. During this period, you may add a replica to a different region, provided you have not had one there within the last seven days.

disablePassivePollerForwarding affects Worker polls only

The disablePassivePollerForwarding Namespace setting controls forwarding behavior for Worker poll traffic only. When enabled, Worker polls that reach a passive replica are not forwarded, and these Workers do not execute Workflows or Activities. Workers receive a NamespaceNotActive error on poll requests and stay connected to execute Workflows and Activities if the replica becomes active. Same-region replicas are not affected by this setting.

Client requests always forwarded from passive replica

Client requests are forwarded from the passive replica to the active region regardless of disablePassivePollerForwarding setting. Forwarded Workflow APIs include: Start Workflow, Signal-with-Start, Signal, Cancel, Terminate, Delete, and Query. Standalone Activity APIs forwarded: Start, Cancel, Terminate, Delete, Pause, Unpause, Reset, Update Activity Options. Standalone Nexus Operation APIs forwarded: Start, Cancel, Terminate, Delete. A Client that reaches the passive replica keeps working and can start Workflows, send Signals, and run Queries successfully.

Set forwarding behavior with temporal cloud CLI

To set the forwarding behavior using the temporal cloud CLI, run: temporal cloud namespace ha update --namespace <namespace>.<account> --passive-poller-forwarding disabled. Set the flag to enabled to re-enable forwarding.

Automatic failovers are default for HA

When a Temporal Cloud Namespace has a replica in a different region or cloud, Temporal Cloud automatically fails over the Namespace to its replica in the event of an outage. This is the recommended and default option.

Disabling automatic failovers voids RTO guarantee

With automatic failovers disabled, Temporal Cloud cannot fail your Namespace over to its replica during an outage. You take responsibility for detecting outages and triggering failover yourself. Temporal's 20-minute RTO does not apply while this setting is disabled.

Disable automatic failovers with tcld

To disable automatic failovers using tcld, run: tcld namespace update-high-availability --namespace <namespace_id>.<account_id> --disable-auto-failover=true. If using API key authentication with --api-key flag, add it directly after tcld command and before namespace update-high-availability. To restore default behavior, change true to false.

Automatic failovers always enabled for Same-region Replication

The disable-auto-failover setting applies only to Multi-region and Multi-cloud Replication. You cannot disable automatic failovers for a Same-region Replication Namespace, because same-region failovers between cells are always managed by Temporal.

Remove replica to disable High Availability

To disable High Availability features on a Namespace, remove the replica. Removing a replica discontinues replication of Workflows, disables the Namespace's ability to trigger a failover to a different region or cloud, and ends High Availability charges.

Remove replica using tcld

To remove a replica from a Namespace using tcld, run: tcld namespace delete-region --api-key <api_key> --namespace <namespace_id>.<account_id> --region <replica_region_name>. See Regions page for available region names.

Give your agent this brain