Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Upgrading to Enterprise PKS 1.7 fails on the "Running errand PKS 1.7.x Upgrade - MySQL Clone" step (79002)

Last Updated: 5/8/2020Categories: TroubleshootingTotal Views: 2947Language:
English

2 like this article

Subscribe to get an email
newsletter with new updates

2 people found this helpful Please provide article feedback:

Symptoms

Upgrading from Enterprise PKS 1.6.1 to PKS 1.7 fails on "Running errand PKS 1.7.x Upgrade - MySQL Clone) for Enterprise PKS" step.

In the install log, you see the entries similar to the following:

VERIFY CHECKSUM FOR UAA AND TELEMETRY Database cloning failed; checksums for UAA and/or Telemetry do not match!

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Cause

After the PKS-API VM is up, the Mysql Clone DB errand runs. Whenever there is a difference in the entries between the old and new database, the cloning errand fails with the error "VERIFY CHECKSUM FOR UAA AND TELEMETRY Database cloning failed; checksums for UAA and/or Telemetry do not match!" This issue can occur when LDAP is enabled in UAA and  the new database has an updated LDAP entry that the old database does not.

The clone errand happens after the PKS-API VM is up and between the time UAA comes online after the Enterprise PKS  1.7 upgrade finishes and before the clone-db script finishes cloning. There exists a small window of time where if a record is changed in LDAP (or someone logs in to Enterprise PKS), a record (or records) will change in the new database and cause the clone errand to fail.

Resolution

This is a known issue affecting Enterprise PKS 1.7. There is currently no resolution.

Workaround

When the clone-db errand fails, start troubleshooting the issue by checking the list of entries that are different between the old and new databases. The following steps can be used to compare the two databases:

Login to the pks-db vm from bosh by running:

bosh ssh -d pivotal-container-<service-instance-id> pks-db/<instance-id>

Check the number of entries in the new DB SQL file:

cat /var/vcap/bosh/cloned_mysql_backup.sql  | wc -l

Check the number of entries in the original (old) DB SQL file:

cat /var/vcap/bosh/original_verify_mysql_backup.sql | wc -l

You can run a diff against both files to see what the change is between these two databases or use a utility like IDE tool to compare both the entries.

You can also login to the Mysql UAA DB and then check all the tables and entries in those using the below steps:

Log in to PKS API vm by running:

bosh ssh -d DEPLOYMENT_NAME pivotal-container-service/0

Log in to the MySQL database that is running on this VM by running this command:

mysql -h 127.0.0.1 -P 13306 -u USERNAME -p PASSWORD

Note: You can find the username and password information in the /var/vcap/jobs/pxc-mysql/config/mylogin.cnf file.

Access the UAA DB by running use uaa;

To get all the tables and concatenate them, run the following command:

SELECT CONCAT(     'SELECT "',      table_name,      '" AS table_name, COUNT(*) AS exact_row_count FROM '',      table_schema,     ''.'',     table_name,      '' UNION ' )  FROM INFORMATION_SCHEMA.TABLES  WHERE table_schema = 'uaa';

To get the count of all the entries in all the tables in UAA DB, run the following command:

SELECT "authz_approvals" AS table_name, COUNT(*) AS exact_row_count FROM uaa.authz_approvals UNION
SELECT "expiring_code_store" AS table_name, COUNT(*) AS exact_row_count FROM uaa.expiring_code_store UNION
SELECT "external_group_mapping" AS table_name, COUNT(*) AS exact_row_count FROM uaa.external_group_mapping UNION
SELECT "group_membership" AS table_name, COUNT(*) AS exact_row_count FROM uaa.group_membership UNION
SELECT "groups" AS table_name, COUNT(*) AS exact_row_count FROM uaa.groups UNION
SELECT "identity_provider" AS table_name, COUNT(*) AS exact_row_count FROM uaa.identity_provider UNION
SELECT "identity_zone" AS table_name, COUNT(*) AS exact_row_count FROM uaa.identity_zone UNION
SELECT "mfa_providers" AS table_name, COUNT(*) AS exact_row_count FROM uaa.mfa_providers UNION
SELECT "oauth_client_details" AS table_name, COUNT(*) AS exact_row_count FROM uaa.oauth_client_details UNION
SELECT "oauth_code" AS table_name, COUNT(*) AS exact_row_count FROM uaa.oauth_code UNION
SELECT "revocable_tokens" AS table_name, COUNT(*) AS exact_row_count FROM uaa.revocable_tokens UNION
SELECT "schema_version" AS table_name, COUNT(*) AS exact_row_count FROM uaa.schema_version UNION
SELECT "sec_audit" AS table_name, COUNT(*) AS exact_row_count FROM uaa.sec_audit UNION
SELECT "service_provider" AS table_name, COUNT(*) AS exact_row_count FROM uaa.service_provider UNION
SELECT "user_google_mfa_credentials" AS table_name, COUNT(*) AS exact_row_count FROM uaa.user_google_mfa_credentials UNION
SELECT "user_info" AS table_name, COUNT(*) AS exact_row_count FROM uaa.user_info UNION
SELECT "users" AS table_name, COUNT(*) AS exact_row_count FROM uaa.users ;

Log in to the new Database by following the below steps:

bosh ssh -d pivotal-container-<service-instance-id> pks-db/<instance-id>

Log in to the MySQL database that is running on this VM by running the following command:

mysql -h 127.0.0.1 -P 13306 -u USERNAME -p PASSWORD

Note: You can find the username and password information in the mysql --defaults-file available at /var/vcap/jobs/pxc-mysql/config/mylogin.cnf.

Follow the above steps a-c again to get the count of entries in all the tables in the UAA DB and compare them with the old one.

Typically, there will be a mismatch in the user_info table and the new database will have more entries than the old one. You can either insert the missing entry (or entries) into the old UAA database and then run the clone-db errand manually, or you can comment the line that checks the entries between the old and new database and exits the clone-db errand from the "clone-db" script.

To edit the clone-db script login to the pks-db vm using bosh ssh :

bosh ssh -d pivotal-container-<service-instance-id> pks-db/<instance-id>

vi /var/vcap/packages/clone-db/bin/clone-db

Go to line number 201 which has the content "exit 1". Comment the line and then save the file.

Run the clone-db errand manually using a command similar to the following:

bosh -d pivotal-container-<service-instance-id> run-errand clone-db

Once the errand is complete, click the Apply Changes button again in Opsman.

Note: You can perform sanity testing by running the pks clusters and pks get-credentials commands to make sure you are able to list the clusters and login to the clusters. Subsequently, you can run kubectl commands against your clusters to make sure that the kubernetes components are accessible.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
Workspace ONE Intelligence for Consumer Apps 2020/05/06 リリースのお知らせ (78963)

KB
•
VMware AirWatch Relay Service 4.3 for Android リリースのお知らせ (79016)

KB
•
VMware Workspace ONE Intelligent Hub 20.04 for Android リリースのお知らせ (78888)

Results 1-3 of 3

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware PKS

Related Versions:

VMware PKS 1.x

VMware PKS 1.7.x

Take Our Survey

Support Assistant