Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Back up your existing Trifacta instance

We'll make two backups: one of the Trifacta software and one of the entire EC2 Instance.

  1. SSH to your current Marketplace instance. Example: ssh -i MyKey.pem centos@TrifactaServer.MyCompany.net

  2. Become Root on the server

    Code Block
    sudo su


  3. Stop the 

    D s platform
     on your current Marketplace instance:

    Code Block
    service trifacta stop


  4. Run the Trifacta backup script:

    Code Block
    /opt/trifacta/bin/setup-utils/trifacta-backup-config-and-db.sh

     

    1. When the script is complete, the output identifies the location of the backup. Example:

      Code Block
      /opt/trifacta-backups/trifacta-backup-5.0+126.20171217124021.a8ed455-20180514213601.tgz


  5. Store the backup in a safe location. We recommend either S3 or copying it to your local computer via SCP.

    1. To copy the backup to the S3 bucket used by your installation you can use this example:

      Code Block
      aws s3 cp /opt/trifacta-backups/trifacta-backup-5.0+126.20171217124021.a8ed455-20180514213601.tgz s3://<my-trifacta-s3-bucket>/trifacta-backups/


    2. If you choose to use SCP note that the AMI does not allow root login, you must copy files you want to the Centos user's home directory and make any permissions changes necessary to allow the Centos user to read them. Once you've done that you can use SCP to copy the files, for example:

      Code Block
      scp -i <my-key.pem> centos@<my-server-ip>:./example-file.txt ./


  6. We recommend that you also take a snapshot of the EBS volume backing your EC2 instance.
    1. This will not be necessary to restore Trifacta but can be useful if you find that you had additional files or configurations that you need to replicate once your new Trifacta instance is running.

Perform the Cloudformation Stack upgrade

In this section, you will upgrade the Cloudformation Stack which will bring up the latest copy of Trifacta as well as perform any necessary adjustments to your existing resources.

Steps:

  1. Upgrade the Cloudformation Stack

  2. Visit the Trifacta Marketplace listing page for your product

  3. Scroll down to under "View Usage Instructions"
  4. Expand the "View CloudFormation Template" section
  5. Right click the "Download CloudFormation Template" link and copy it's URL
  6. Go to CloudFormation in your AWS Console
  7. Click your Trifacta Stack
  8. Click "Update"
  9. Select "Replace Current Template"
  10. Select "Amazon S3 URL" and paste the link to the template in the text box.

  11. Click next and review the parameters, they should be inherited from your existing Stack.

  12. Wait until the CloudFormation Stack indicates it's upgraded
  13. Now try to access the Trifacta software via the URL in the "Outputs" tab of CloudFormation.
  14. When it brings you to a login page, the software has started and we can continue.

Restore your backup onto the new instance

  1. Connect to your new Trifacta instance via SSH.

    1. Note that the IP address has changed.

  2. Become Root on the Trifacta instance

    Code Block
    sudo su
    cd


  3. The Trifacta software will start automatically on boot. Stop it before continuing:

    Code Block
    service trifacta stop


  4. Download the latest copy of the restore script to pick up additional fixes that have been made. note: this step is required

    Code Block
    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


  5. Download the backup from your storage location and extract its contents. Example:

    Code Block
    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>


  6. Execute the restore script. Pass in the path to your unzipped backup as a parameter. Example:

    Code Block
    /opt/trifacta/bin/setup-utils/trifacta-restore-from-backup.sh -r /root/trifacta-restore-files/trifacta-backup-5.1+126.20171217124021.a8ed455-20180514213601


  7. Start up the product

    Code Block
    service trifacta start


  8. Verify that the product is working as expected by running jobs.





Appendix - this content may be applicable to you depending on your specific configuration

Upgrade from Release 5.1 or earlier

Photon scaling factor has been removed

Info

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:

Code Block
"webapp.client.loadLimit": 10485760,
"webapp.client.maxResultsBytes": 41943040,


Info

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.

Update Data Service properties

Info

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. 

Steps:


  1. D s config
    methodt
  2. Locate the  data-service.classpath setting. Change the class path value to point to the correct directory:

    Code Block
    /opt/trifacta/conf/data-service


  3. Locate the webapp.connectivity.kerberosDelegateConfigPath setting. If you are enabling Kerberos-based SSO for relational connections, please add the following value to the path:

    Code Block
    "%(topOfTree)s/services/data-service/build/conf/kerberosdelegate.config"

    For more information, see Enable SSO for Relational Connections.

  4. Save the file.

SSO signout updates

Info

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 

D s webapp
 may not work when SSO is enabled. This issue applies to the reverse proxy method of SSO for AD/LDAP. 

Info

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:

Steps:

  1. Login to the 
    D s item
    itemnode
    .
  2. Edit the following file:

    Code Block
    /opt/trifacta/pkg3p/src/tripache/conf/conf.d/trifacta.conf


  3. Add the following rule for the /unauthorized path:
    Image Modified

  4. Modify the redirection for /sign-out from / to /unauthorized. Remove the rewrite rule:
    Image Modified
  5. Save the file and restart the platform.

Troubleshooting - disambiguating email accounts

Info

Applies if: Applies to all upgrades to Release 6.0.1 and later.

In Release 6.0.1, the 

D s platform
 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:

Code Block
| <Id> | <Email> | other columns |
| 1 | foobar@trifacta.com | * |
| 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 and FOOBAR) are disambiguated. After upgrade the People table might look like the following:

Code Block
| <Id> | <Email> | other columns |
| 1 | foobar@trifacta.com_duplicate_1 | * |
| 2 | foobar@trifacta.com_duplicate_2 | * |
| 3 | foobar@trifacta.com | * |

Notes:

  • The email address with the highest Id value in the People table is assumed to be the original user account.
  • The format for email addresses is: 

    Code Block
    <orig_userId>_duplicate_<row_id>

    where <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: all-emails-for-people-to-lower-case.

A set of users without duplicates has the following entry:

Code Block
== 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:

Code Block
== 20181107131647-all-emails-for-people-to-lower-case: migrating =======
warn: List of duplicated emails: foobar@trifacta.com_duplicate_1, foobar@trifacta.com_duplicate_2
== 20181107131647-all-emails-for-people-to-lower-case: migrated (0.201s)


Info

NOTE: The above log entry indicates that there are duplicated user accounts.

Suggested approach:

  1. Change ownership on all flows in secondary accounts to the primary account.

  2. Delete secondary accounts.

...