How Can I Confirm That My NuoDB Upgrade Completed Successfully?
Nice work! You just upgraded your NuoDB environment. (If you haven’t done this step, my four simple steps to upgrading your NuoDB database post might help you.)
So now that you’ve upgraded your environment, how can you be sure your upgrade process has completed? After all, your environment probably contains more than one node, right? So, what happens if you missed one? How can you be sure that you’ve completely upgraded your database?
This can be a bit confusing sometimes because when you upgrade your environment, you do it at two levels. One upgrade is on the protocol level, and the other one is on the database level.
In this post, I’m going to show you an upgrade that has completed successfully and explain what a partial upgrade looks like so you know what to look for in both cases. Below is an example after upgrading to NuoDB v3.4.4-2, which I will show two ways, using NuoAgent and NuoAdmin, because we have customers who are using both.
Complete Upgrade of the Database Protocol
Here’s a database protocol upgrade that completed successfully, using NuoDBMgr (NuoAgent) for this example:
nuodb [domain] > show database version database test_nuodb details true
Database Version: 3.4|3.4.1|3.4.2|3.4.3|3.4.4
Available Upgrade Versions: None
Node Versions:
192.168.128.2:48005 [ nodeId = 5 ] Release 3.4.4-2-560b26fa89 (Version 3.4|3.4.1|3.4.2|3.4.3|3.4.4)
192.168.128.3:48005 [ nodeId = 7 ] Release 3.4.4-2-560b26fa89 (Version 3.4|3.4.1|3.4.2|3.4.3|3.4.4)
192.168.128.3:48006 [ nodeId = 8 ] Release 3.4.4-2-560b26fa89 (Version 3.4|3.4.1|3.4.2|3.4.3|3.4.4)
192.168.128.2:48006 [ nodeId = 9 ] Release 3.4.4-2-560b26fa89 (Version 3.4|3.4.1|3.4.2|3.4.3|3.4.4)
As you can see by the fact that all nodes list the same set of versions values
“(3.4|3.4.1|3.4.2|3.4.3|3.4.4)”, all of the versions in every node are the same: 3.4.4. Perfect!
Here’s an upgrade that completed successfully, using nuocmd (NuoAdmin) for this example:
# nuocmd show database-versions --db-name nuodb_test
effective version ID: 1310720, effective version: 4.0|4.0.1, max version ID: 1310720
Available versions:
Process versions:
version ID: 1310720, version: 4.0|4.0.1, release: 4.0.1-1-ced7ff7377
[SM] container-1:48006 [start_id = 4] [server_id = server0] [pid = 21892] [node_id = 5] [last_ack = 0.80] MONITORED:RUNNING
[TE] container-1:48007 [start_id = 5] [server_id = server0] [pid = 21946] [node_id = 6] [last_ack = 7.80] MONITORED:RUNNING
[SM] container-2:48007 [start_id = 6] [server_id = server1] [pid = 8702] [node_id = 8] [last_ack = 10.81] MONITORED:RUNNING
[TE] container-2:48006 [start_id = 8] [server_id = server1] [pid = 8940] [node_id = 9] [last_ack = 6.79] MONITORED:RUNNING
With nuocmd, since all of the nodes are listed under then single version ID, all of the nodes have been upgraded to the same database protocol version.
Partial Upgrade of the Database Protocol
Here’s an example of a partial upgrade of the database protocol. This example uses nuocmd (NuoAdmin). In this example, the original version was 3.4.3-1 and only one node (te1) was upgraded to version 4.0-1.
nuocmd show database-versions --db-name test
effective version ID: 1245184, effective version: 3.4, max version ID: 1245184
Available versions:
Process versions:
version ID: 1245184, version: 3.4, release: 3.4.3-1-9e6ec78560
[SM] sm1/192.168.16.4:48006 [start_id = 0] [server_id = nuoadmin0] [pid = 41] [node_id = 1] [last_ack = 1.19] MONITORED:RUNNING
[SM] sm2/192.168.16.5:48006 [start_id = 1] [server_id = nuoadmin1] [pid = 38] [node_id = 2] [last_ack = 1.18] MONITORED:RUNNING
[TE] te2/192.168.16.8:48006 [start_id = 3] [server_id = nuoadmin1] [pid = 38] [node_id = 4] [last_ack = 1.19] MONITORED:RUNNING
version ID: 1310720, version: 4.0, release: 4.0-1-2f01499300
[TE] te1/192.168.16.6:48006 [start_id = 4] [server_id = nuoadmin0] [pid = 40] [node_id = 5] [last_ack = 2.09] MONITORED:RUNNING
As you can see in this example, there are multiple release versions showing up (bold added for emphasis). While this is normal as you perform a rolling upgrade, it's not recommended to run a database that's partially upgraded for an extended period of time.
Read more about show database-version in our documentation.
Complete Upgrade at the Database Level
Using NuoSQL, you can verify whether all nodes were upgraded to a particular release version by checking system.nodes. If you forgot to upgrade any node, it will show a different release-version value here.
SQL> select * from system.nodes;
ID LOCALID PORT ADDRESS HOSTNAME STATE TYPE CONNSTATE MSGQSIZE TRIPTIME GEOREGION PLATFORM_VER RELEASE_VER
--- -------- ----- ------------- -------------------------------- ------- ----------- ---------- --------- --------- -------------- ------------- ------------------
5 2 48005 192.168.128.2 container1.3.2.3-net Running Storage Ready 2 508 DEFAULT_REGION 1245184 3.4.4-2-560b26fa89
7 3 48005 192.168.128.3 container2 Running Storage Ready 2 380 DEFAULT_REGION 1245184 3.4.4-2-560b26fa89
8 0 48006 192.168.128.3 container2 Running Transaction Ready 0 0 DEFAULT_REGION 1245184 3.4.4-2-560b26fa89
9 1 48006 192.168.128.2 container1.3.2.3-net Running Transaction Ready 2 390 DEFAULT_REGION 1245184 3.4.4-2-560b26fa89
Read more about system.nodes in our documentation.
The next query checks whether you performed the SQL-level upgrade step: "upgrade database
SQL> SELECT geteffectiveplatformversion() FROM DUAL;
GETEFFECTIVEPLATFORMVERSION
----------------------------
1245184
The following output shows that the last step was completed successfully; the database protocol was upgraded. It means a new transaction engine (TE) was started, which is the last step of the upgrade.
You can see in the query result below that some property version values remain the same as their original installation (1048576), while others were updated to a higher value (1245184). The ones that were updated to the new value are the properties on which a code change was applied in the upgraded release.
SQL> select * from system.versions
PROPERTY VERSION
--------------------------------------------- --------
TABLEID_UPGRADE 1048576
DECLARED_TYPE_UPDATED_IN_ALLSYSTEMFIELDS 1048576
USER_PRIVILEGES_UPDATED 1048576
ACTIVE_USERROLE_UPGRADE 1048576
SYSTEM_IDENTITY_TYPES_UPDATED 1048576
PRIVILEGES_PER_SCHEMA_UPGRADED 1048576
CONSTRAINTS_UPGRADED 1048576
STORED_PROC_DYNAMIC_SQL_UPGRADED 1048576
BASIC_CURSORS_UPGRADED 1048576
SYSTEM_EXTERNAL_USERS_UPDATED 1048576
SCHEMA_SCHEMA_UPGRADED 1048576
INSENSITIVE_CURSORS_UPGRADED 1048576
AU_VIEWS_AND_STORED_PROC_CDAU_VIEWS_UPGRADED 1048576
FOREIGN_KEYS_UPGRADED 1048576
BASIC_WINDOW_FUNCTIONS_UPGRADED 1048576
STATEMENT_LEVEL_TRIGGER_NOTIFICATION_UPGRADED 1048576
DATABASE_LEVEL_TRIGGER_UPGRADED 1048576
EXECUTE_IMMEDIATE_MULTI_STATEMENT_UPGRADED 1048576
TDDL_UNIQUE_IDS_UPDATED 1048576
TRANSACTIONAL_LOCKS_ENABLED 1048576
TRIGGER_UNIQUE_NAME_UPDATED 1048576
INDEX_UNIQUE_NAME_UPDATED 1048576
SYSTEM_TABLES_VERSION 1245184
RENAMED_TABLE_SEQUENCES_UPGRADE 1048576
SEQUENCE_TYPE_SAFETY_UPGRADE 1048576
TABLES_POST_204 1048576
ADVANCED_TDDL_UNIQUE_IDS_UPDATED 1245184
USER_PRIVILEGES_FIXED 1245184
TYPE_CHECKING_ALWAYS_ON_UPGRADED 1245184
INDEX_FORMAT_UPGRADED 1245184
FOREIGN_KEY_TYPES_UPGRADED 1245184
Read more about system.versions in our documentation.
Partial Upgrade at the Database Level
You can see in the query result below that ALL property version values remain the same as their original installation (1048576). It means that the last step of the upgrade, restart/start a transaction engine (TE) has not been completed yet. If this is not your first upgrade on this database, the result of this query will show all the same values that you had when you completed your last upgrade, but there will be no indication/value of this upgrade (1245184) to any property.
SQL> select * from system.versions;
PROPERTY VERSION
--------------------------------------------- --------
TABLEID_UPGRADE 1048576
DECLARED_TYPE_UPDATED_IN_ALLSYSTEMFIELDS 1048576
USER_PRIVILEGES_UPDATED 1048576
ACTIVE_USERROLE_UPGRADE 1048576
SYSTEM_IDENTITY_TYPES_UPDATED 1048576
PRIVILEGES_PER_SCHEMA_UPGRADED 1048576
CONSTRAINTS_UPGRADED 1048576
STORED_PROC_DYNAMIC_SQL_UPGRADED 1048576
BASIC_CURSORS_UPGRADED 1048576
SYSTEM_EXTERNAL_USERS_UPDATED 1048576
SCHEMA_SCHEMA_UPGRADED 1048576
INSENSITIVE_CURSORS_UPGRADED 1048576
AU_VIEWS_AND_STORED_PROC_CDAU_VIEWS_UPGRADED 1048576
FOREIGN_KEYS_UPGRADED 1048576
BASIC_WINDOW_FUNCTIONS_UPGRADED 1048576
STATEMENT_LEVEL_TRIGGER_NOTIFICATION_UPGRADED 1048576
DATABASE_LEVEL_TRIGGER_UPGRADED 1048576
EXECUTE_IMMEDIATE_MULTI_STATEMENT_UPGRADED 1048576
TDDL_UNIQUE_IDS_UPDATED 1048576
TRANSACTIONAL_LOCKS_ENABLED 1048576
TRIGGER_UNIQUE_NAME_UPDATED 1048576
INDEX_UNIQUE_NAME_UPDATED 1048576
SYSTEM_TABLES_VERSION 1048576
RENAMED_TABLE_SEQUENCES_UPGRADE 1048576
SEQUENCE_TYPE_SAFETY_UPGRADE 1048576
TABLES_POST_204 1048576
ADVANCED_TDDL_UNIQUE_IDS_UPDATED 1048576
USER_PRIVILEGES_FIXED 1048576
TYPE_CHECKING_ALWAYS_ON_UPGRADED 1048576
INDEX_FORMAT_UPGRADED 1048576
FOREIGN_KEY_TYPES_UPGRADED 1048576
What To Do With A Partial Upgrade
Now that you know what to look for, I’m sure you’re wondering how you fix it if you do see that you’ve only partially upgraded your database. Once you see an indication of a partial upgrade, all you need to do is complete all the upgrade steps.
I hope this information helpful. Once your NuoDB database is completely upgraded you’ll be able to take full advantage of the features in your latest version.