Skip to content

DOC-1008 Update upgrade.adoc #969

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
priyankagunaki-cloud wants to merge 1 commit into
base: 4.3
Choose a base branch
from
Open

DOC-1008 Update upgrade.adoc #969

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 15 additions & 2 deletions modules/installation/pages/upgrade.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,14 @@
This page describes the steps to upgrade an existing installation of
TigerGraph to TigerGraph {page-component-version}.

== Choosing an Upgrade Strategy

The right upgrade approach depends on your cluster's configuration and how much downtime it can tolerate.

* *Production clusters with a replica (recommended for production):* use xref:upgrade.adoc#_rolling_upgrade[Rolling Upgrade] to keep the cluster online during maintenance updates, with disruption limited to brief leader switch events.
* *Critical production clusters that require near-zero downtime and instant rollback:* consider a blue-green deployment strategy, where a second, upgraded cluster is stood up and validated against real workload before traffic is switched over. This is not a built-in TigerGraph feature -- it is a system architecture pattern that you design and operate using TigerGraph's replica and HA building blocks.
* *Development clusters without a replica that can tolerate downtime:* a standard (non-rolling) upgrade is sufficient. See xref:upgrade.adoc#upgrading-from-v3x[Upgrading from v3.x] for the expected downtime factors.

== Before you begin

=== Check release notes for changes in functionality
Expand Down Expand Up @@ -123,7 +131,9 @@ gadmin crr start
[#_rolling_upgrade]
== Rolling Upgrade (Preview)

A rolling upgrade allows you to upgrade your TigerGraph installation with minimal downtime by upgrading nodes in batches, ensuring that at least one full replica of the cluster is online throughout the process.
A rolling upgrade allows you to upgrade your TigerGraph installation with minimal service disruption by upgrading nodes in batches, ensuring that at least one full replica of the cluster remains online throughout the process. Under normal conditions, service interruptions are typically limited to leader switch events, which generally complete within a few seconds to approximately 1–2 minutes, depending on the cluster topology and upgrade strategy. If leaders are upgraded together, total disruption is roughly one leader switch; if upgraded one partition at a time, it scales with the number of partitions.

Each node upgrade also includes a brief pause of about one minute between stopping RESTPP and NGINX, allowing load balancers to detect the change and stop forwarding traffic to that node before it goes offline.

* Rolling Upgrade is only available for HA (High Availability) clusters.
* Rolling Upgrade is supported only for maintenance updates (for example, 4.2.x to 4.2.1, or 4.3.1 to 4.3.3). Upgrading from 4.2.0 to 4.3.0 or another major version is not supported.
Expand Down Expand Up @@ -364,10 +374,13 @@ For example, if you are upgrading from 3.5.0 to 4.1.x, upgrade to 3.5.3 first us
Additionally, versions upgrading from 3.0 or 3.1 must first go through 3.2.4.
For example, if you are running version 3.1.3, you must first upgrade to 3.1.6, then 3.2.4, then to 3.10.x.


[IMPORTANT]
====
When switching to a new version of TigerGraph it will stop the current services which will make the cluster temporarily unavailable.

The upgrade runs through a sequence of pre-upgrade checks, a version switch, and post-upgrade checks across the infra, engine, GSQL, and GUS components (see xref:upgrade.adoc#_nn_option_2[n/N option] for the full script sequence). Of these, the GSQL steps typically take the longest, since they perform full catalog validation, including query syntax checks, query installation, and UDF compatibility checks to ensure the new version is compatible with your existing schema and queries.

Total downtime depends on your schema size and complexity, the number of installed queries, and whether UDFs are in use, so an exact duration cannot be guaranteed in advance. Clusters with large or complex schemas and many installed queries should expect longer downtime than clusters with simple schemas and few queries.
====

Any 3.x version of TigerGraph can be upgraded to another v3.x version by
Expand Down