This guide steps through the requirements and process for upgrading through the AWS Marketplace.
Upgrading to the latest version of via the AWS Marketplace terminates your existing instance and creates a new instance with the latest software in its place. Please follow these instructions carefully.
Your is deployed as part of a Cloudformation Stack. When you upgrade this Stack, Cloudformation informs you of the resources that it plans to modify and then manages the modifications.
This upgrade process supports upgrade for the following versions:
|Source Version||Target Upgrade Version|
If you are upgrading from a version that is earlier than the supported Source Version listed above for this upgrade process, please use the links below to acquire the AMI(s) and documentation to upgrade to the earliest supported Source Version. Then, return to these instructions to complete the upgrade to this version.
|Your Version||Target Version||AMI||Documentation|
|Please see the AWS Marketplace listing for the product. The AMI is accessible from there.||Trifacta Install Guide for AWS Marketplace with EMR v5.0|
/opt/trifacta/license/license.jsonto restore it after the upgrade.
This process creates two backups: one of the and one of the entire EC2 Instance.
SSH to your current Marketplace instance. Example:
ssh -i MyKey.pem centos@TrifactaServer.MyCompany.net
Switch to Root user on the server:
Stop the on your current Marketplace instance:
service trifacta stop
Run the :
When the script is complete, the output identifies the location of the backup. Example:
Store the backup in a safe location. You should copy it to either S3 or to your local computer via SCP.
To copy the backup to the S3 bucket used by your installation, you can use this example:
aws s3 cp /opt/trifacta-backups/trifacta-backup-5.0+126.20171217124021.a8ed455-20180514213601.tgz s3://<my-trifacta-s3-bucket>/trifacta-backups/
If you choose to use SCP, please note that the AMI does not allow root login. You must copy the files to the CentOS user's home directory and modify any permissions to allow the CentOS user to read them. After that, you can use SCP to copy the files. Example:
On the server: chown centos:centos mybackupfile.tgz On your workstation: scp -i <my-key.pem> centos@<my-server-ip>:./example-file.txt ./
Please complete the following steps to upgrade the Cloudformation Stack. These steps create an instance of the latest version of and then performs any necessary adjustments to your existing resources.
Visit the Marketplace listing page for your product.
Click Next to review the parameters. In the latest version of the CloudFormation template we have updated the EMR cluster with some new features:
Connect to your new via SSH.
If you receive an SSH fingerprint warning, it is expected when connecting to a new instance.
Switch to Root user on the :
sudo su cd
Restore your license file or create a new license file with the contents you copied earlier. Review and update the permissions and ownership appropriately:
chown trifacta:trifacta /opt/trifacta/license/license.json chmod 755 /opt/trifacta/license/license.json
Download the latest copy of the restore script to pick up additional fixes that have been made.
NOTE: This step is required.
curl --output trifacta-restore-from-backup.sh https://raw.githubusercontent.com/trifacta/trifacta-utils/release/6.0/trifacta-restore-from-backup.sh mv trifacta-restore-from-backup.sh /opt/trifacta/bin/setup-utils/trifacta-restore-from-backup.sh chown trifacta:trifacta /opt/trifacta/bin/setup-utils/trifacta-restore-from-backup.sh chmod 775 /opt/trifacta/bin/setup-utils/trifacta-restore-from-backup.sh
Download the backup from your storage location and extract its contents. Example:
mkdir -p /root/trifacta-restore-files cd /root/trifacta-restore-files aws s3 cp s3://<my-trifacta-s3-bucket>/trifacta-backups/<my-backup-file.tgz> . tar xzf <my-backup-file.tgz>
Execute the restore script. Pass in the path to your unzipped backup as a parameter. Example:
/opt/trifacta/bin/setup-utils/trifacta-restore-from-backup.sh -r /root/trifacta-restore-files/trifacta-backup-5.1+126.20171217124021.a8ed455-20180514213601
Start up the platform:
service trifacta start
In the menu, navigate to Settings > Admin Settings.
spark.version. Verify that it is
In the AWS S3 console, navigate to the following:
<Resource Bucket>/<Resource Path>/trifacta/libs/
Verify that the product is working as expected by running jobs.
NOTE: Upon upgrade to Release 6.0 and later, relational writeback is automatically enabled.
Existing relational connections are not automatically enabled with writeback.
Applies if: You modified the Photon scaling properties in your pre-upgrade environment.
In Release 6.0, the Photon scaling factor parameter (
photon.loadScalingFactor) has been removed. As part of this change, the following parameters are automatically set to new values as part of the upgrade. The new values are listed below:
"webapp.client.loadLimit": 10485760, "webapp.client.maxResultsBytes": 41943040,
NOTE: If you had not modified either of the above values previously, then no action is required. If you had changed these values before upgrading, the settings are set to the new default values above.
Applies if: You modified the Data Service classpath in your pre-upgrade environment.
After you have upgraded, the Data Service fails to start.
In Release 6.0.0, some configuration files related to the Data Service were relocated, so the classpath values pointing to these files need to be updated.
data-service.classpath setting. Change the class path value to point to the correct directory:
webapp.connectivity.kerberosDelegateConfigPath setting. If you are enabling Kerberos-based SSO for relational connections, please add the following value to the path:
For more information, see Enable SSO for Relational Connections.
Applies if: You were using or plan to use the Tableau Server integration.
Due to licensing issues, all existing customers who are using the Tableau integration must license, download and install the Tableau SDK if upgrading to Release 6.0.2 and onward.
Applies if: You have installed the on MySQL.
When upgrading to Release 6.0.x, there is a known issue in which the MySQL driver JAR is not properly installed for the new Configuration Service. This causes a
No suitable driver found error for the
The fix is to apply copy the MySQL driver to the correct location for Configuration Service in Release 6.0.x.
Locate the MySQL driver. A version of it should be available in one of the following locations:
/opt/trifacta/services/batch-job-runner/build/install/batch-job-runner/lib/mysql-connector-java-6.0.6.jar /opt/trifacta/services/scheduling-service/server/build/install/scheduling-service/lib/mysql-connector-java-6.0.6.jar /opt/trifacta/services/time-based-trigger-service/server/build/install/time-based-trigger-service/lib/mysql-connector-java-6.0.6.jar
Relocate the driver to the following location:
For more information on MySQL installation, see Install Databases for MySQL.
Applies if: You have enabled SSO for AD/LDAP and have noticed that logout is not working.
After upgrading to this release, signing out of the may not work when SSO is enabled. This issue applies to the reverse proxy method of SSO for AD/LDAP.
NOTE: Beginning in Release 6.0, a platform-native method of SSO is available. This new method is recommended.
Some properties related to the reverse proxy must be updated. Please complete the following:
Edit the following file:
Add the following rule for the
/unauthorized. Remove the rewrite rule:
Applies if: You customized any relational connections through modifications of the configuration files in the pre-upgrade environment.
If you have created custom relational connections, the configurations need to be re-applied to the default configurations in the upgraded software. Depending on the pre- and post-upgrade versions, the properties and expected values may have changed significantly.
Applies if: Your EC2 installation is integrated with a PostgreSQL database.
If you have upgraded the on an EC2 instance to Release 6.0.0 or later, the platform may not start due to a problem authenticating to the when it is hosted on PostgreSQL.
The problem is that the password of the , the main one, was reset to the EC2 instance ID.
The solution is to reset the password to
trifacta for the
trifacta user, which is the default password. At the command line, execute the following:
NOTE: A DBA should execute the following. The database, user, password values can be modified as needed. You should avoid using default passwords for your databases.
psql -d trifacta -U trifacta pwd: <instanceID> \password trifacta
After the password is reset, the platform should restart successfully.
Applies if: Applies to all upgrades to Release 6.0.1 and later.
In Release 6.0.1, the permitted case-sensitive email addresses. So for purposes of creating user accounts, the following could be different userIds in the platform. Pre-upgrade, the People table might look like the following:
| <Id> | <Email> | other columns | | 1 | firstname.lastname@example.org | * | | 2 | FOOBAR@trifacta.com | * | | 3 | FooBar@trifacta.com | * |
Beginning in Release 6.0.2, all email addresses (userIds) are case-insensitive, so the above distinctions are no longer permitted in the platform.
As of Release 6.0.2, all email addresses are converted to lower-case. As part of the upgrade to Release 6.0.2, any email addresses that are case-insensitive matches (
FOOBAR) are disambiguated. After upgrade the People table might look like the following:
| <Id> | <Email> | other columns | | 1 | email@example.com_duplicate_1 | * | | 2 | firstname.lastname@example.org_duplicate_2 | * | | 3 | email@example.com | * |
The format for email addresses is:
<row_id> is the row in the table where the duplicate was detected.
After all migrations have completed, you should review the migration logs. Search the logs for the following:
A set of users without duplicates has the following entry:
== 20181107131647-all-emails-for-people-to-lower-case: migrating ======= == 20181107131647-all-emails-for-people-to-lower-case: migrated (0.201s)
Entries like the following indicate that duplicate addresses were found for separate accounts. The new
duplicate Ids are listed as part of the message:
== 20181107131647-all-emails-for-people-to-lower-case: migrating ======= warn: List of duplicated emails: firstname.lastname@example.org_duplicate_1, email@example.com_duplicate_2 == 20181107131647-all-emails-for-people-to-lower-case: migrated (0.201s)
NOTE: The above log entry indicates that there are duplicated user accounts.
Change ownership on all flows in secondary accounts to the primary account.
Delete secondary accounts.
Applies if: Your Hadoop cluster sends trash files to an encrypted zone.
For more information on this known issue, see the Troubleshooting section in Configure for Spark.
You can access complete product documentation online and in PDF format. From within the product, select Help menu > Product Docs.