Upgrading an Existing Installation
Before you begin
Check release notes for changes in functionality
Always check the TigerGraph DB Release Notes for all the versions between your current version and your target version, for deprecated features, known issues, or other behavioral changes. You may need to make migration changes to your TigerGraph application either before or after the upgrade. If you have any questions or uncertainty, please contact TigerGraph Support. |
User-defined function (UDF) compatibility
TigerGraph version 3.9 introduced changes in the way user-defined functions are accepted by the system.
-
Some UDFs may no longer be accepted due to increased security screening.
-
UDFs may no longer be called
to_string()
. This is now a built-in GSQL function. -
UDF names may no longer use the
tg_
prefix.
If any UDFs do not satisfy these restrictions, then they will not be installed. GSQL will return these errors:
tg_
prefix errorThe following function name(s) contain errors:
[reserved 'tg_']: tg_myFunction
Please rename the corresponding functions in: ExprFunctions.hpp
to_string()
function nameFollowing GSQL built-in function name(s): [to_string] can not be used again for user defined function name(s)!
GSQL built-in functions are case-insensitive. Please rename corresponding user defined functions in ExprFunctions.hpp.
Any user-defined function previously used in an older TigerGraph version that does not comply with these requirements must be renamed or removed in ExprFunctions.hpp
.
Make a Backup
As a precaution, it is always a good idea to make a full backup before performing a major system change like an upgrade. System upgrade does not support version rollback at this time. |
Prepare a pre-3.2 database
-
First perform a backup using GBAR (Graph Backup and Restore) on your existing installation.
-
Restore your installation with GBAR to rebuild it. This step is necessary because TigerGraph 3.2 made major changes to the Graph Storage Engine and a restore is needed to remove certain files that would make the upgrade operation fail.
-
Ensure that the restore is completely finished and there are no pending graph modifications (schema change, insert, update, or delete) before starting the upgrade. You can do this by calling the /rebuildnow endpoint and waiting until there are no more PullDelta messages being printed in the logs.
Ensure that the database is inactive
Ensure that the database will be inactive throughout the upgrade process. |
-
Stop any new database requests.
-
Ensure that all previous operations such as queries, loading jobs, schema changes, and data updates and deletions are completely finished. Check the appropriate logs. Call the /rebuildnow endpoint to force the data store to consume all pending updates and then wait until there are no more PullDelta messages being printed in the logs.
Upgrading a CRR system
To upgrade the TigerGraph software on a CRR system, follow this sequence of steps.
-
Disable CRR on your DR cluster.
$ gadmin config set System.CrossRegionReplication.Enabled false $ gadmin config apply -y $ gadmin restart all -y
-
Upgrade both the primary cluster and DR cluster, according to the instructions on this page.
-
Enable CRR on the DR cluster.
Upgrading from v3.x
When switching to a new version of TigerGraph it will stop the current services which will make the cluster temporarily unavailable. |
Any 3.x version of TigerGraph can be upgraded to another v3.x version by
running the installation script with the upgrade(-U
) flag.
-
Download the latest version of TigerGraph to your system.
-
Extract the tar file.
-
Run the installation script under the Linux user created during installation with the upgrade flag (
-U
) that was extracted from the tar file:
$ ./install.sh -U
Please upgrade from the most recent maintenance version in any minor release. If you are upgrading from a version that does not have the most recent patches applied to its minor version, upgrade to the most recent patches first before upgrading to another minor or major version. For example, if you are upgrading from 3.5.0 to 3.10.x, upgrade to 3.5.3 first using the installation script and then upgrade to 3.10.x. 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. |
Once binaries and config files are installed on local machine and also distributed to all the other machines, a message will be prompted to user:
“Do you want to switch platform to the new version now(it can be delayed to a later time): y/N”.
n/N option
If users selects n/N
, now it is listing a list of scripts taking the same parameters as gadmin/gsql
commands.
[NOTE ]: To switch platform to new version, please follow the instructions: 1. pre_upgrade_check_infra.sh 3.6.5 3.10.0 2. pre_upgrade_check_engine.sh 3.6.5 3.10.0 3. pre_upgrade_check_gsql.sh 3.6.5 3.10.0 4. pre_upgrade_check_gus.sh 3.6.5 3.10.0 5. gadmin config set System.AppRoot /home/graphsql/tigergraph/app/3.10.0 6. gadmin config apply -y 7. switch_version_infra.sh 3.6.5 3.10.0 8. switch_version_engine.sh 3.6.5 3.10.0 9. switch_version_gsql.sh 3.6.5 3.10.0 10. switch_version_gus.sh 3.6.5 3.10.0 11. post_upgrade_check_infra.sh 3.6.5 3.10.0 12. post_upgrade_check_engine.sh 3.6.5 3.10.0 13. post_upgrade_check_gsql.sh 3.6.5 3.10.0 14. post_upgrade_check_gus.sh 3.6.5 3.10.0
These scripts are located in “/home/<user>/tigergraph/app/<version>/upgrade_script
folder.
y/Y Option
If users selects y/Y
the installer will automatically switch TigerGraph to the latest version.
A new message will prompt to user, saying TigerGraph has been upgraded.
If there’s any error, the upgrade process will be terminated immediately. Following the instructions in the prompts from the console, the user can tell the progress of the upgrade and manually re-run the failed and the leftover steps to complete the upgrading process.
Option -n
Users can use option -n
to avoid input y/n
to switch to the new version. When it is given, the upgrade flow will switch to the new version automatically without input from the user.
$ ./install.sh -U -n
./install.sh -U -n
_______ ______ __
/_ __(_)___ ____ _____/ ____/________ _____ / /_
/ / / / __ `/ _ \/ ___/ / __/ ___/ __ `/ __ \/ __ \
/ / / / /_/ / __/ / / /_/ / / / /_/ / /_/ / / / /
/_/ /_/\__, /\___/_/ \____/_/ \__,_/ .___/_/ /_/
/____/ /_/
Welcome to the TigerGraph platform installer!
[PROGRESS]: 20:02:38 Upgrade TigerGraph platform from existing one ...
[NOTE ]: Obtained version of exist platform: 3.10.0 [OK]
Upgrading from v2.x
Please contact TigerGraph Support to coordinate upgrading to TigerGraph version 3.11 if you are currently using a 2.x version of TigerGraph. Even though all the steps are documented, it is strongly recommended that you review the process with the TigerGraph Support team.
Upgrading the Developer Edition or migrating to another edition are not supported.
For detailed upgrade procedures, see our support article on the 2.6.x to 3.x upgrade flow
Upgrading Cloud Marketplace Images
Upgrading from 2.x
If you want to upgrade your Cloud Marketplace image from v2.x on any cloud platform, please open a support ticket. for instructions and assistance.
Known Issues and Workarounds
Several things may have changed between your current release and 3.9.x and these steps should help to upgrade the UDF file before starting the upgrade process or prepare users to address anything that may come up as a result of the upgrade.
to_string()
is Now a Built-in Function:
In previous releases, to_string()
was included in the default ExprFunctions
file and is a common utility function added to the ExprFunctions
file.
What to do:
Users need to rename or remove UDFs that are called to_string()
.
Now, that it is added as a built-in function users are no longer needing to include it in the ExprFunctions
file.
For more reference on how to prepare for an upgrade please refer back to the section: Before You Begin.
tg_
is Now a Reserved Keyword
TigerGraph uses the tg_
prefix to denote functions provided by TigerGraph.
What to do:
Users can either rename, remove, or comment out any functions in their ExprFunctions
file that contain this prefix.
Additionally, users should avoid prefixing future functions with this reserved prefix.
This is to avoid naming collisions with queries.
For more reference on how to prepare for an upgrade please refer back to the section: Before You Begin.
UDF File Policy
There is some UDF enforcement taking place. The UDF files are scanned to make sure they comply with the file policy. This is to ensure there are none of the following:
-
Macros with a
replacement
.Example:#define TABLE_SIZE 100
Notice the macro withoutreplacement
is allowed#define EXPRFUNCTIONS_HPP_
-
Headers
andIncludes
from potentially vulnerable C++ featuresIf the header file is not included in our default
allowlist
, users can, at their own discretion, add C++ headers to anallowlist
. Users are free to edit theallowlist
viagadmin
config setGSQL.UDF.Policy.HeaderAllowlist
.Additionally, users can also disable a file policy after an upgrade with this command:
gadmin config set GSQL.UDF.Policy.Enable false
This is so the restrictions will not take effect.
What to do:
It is recommended that users consult with the entire policy and adjust the UDF files to comply with the file policy.
For more reference please see: UDF File Scanning.
File Output Policy
GSQL restricts where a query can produce output to files through a file output policy. Sometimes users can encounter a issue with this policy after an upgrade.
What to do:
Before (recommended) or after an upgrade users should change or use different constant paths for queries and loading jobs that do not violate policy.
For more on file policy see File Output Policy and/or File Input Policy.
Other issues
For any other issues encountered please contact support@tigergraph.com.