WSO2 Data Analytics Server is succeeded by WSO2 Stream Processor. To view the latest documentation for WSO2 SP, see WSO2 Stream Processor Documentation.

All docs This doc

Versions Compared


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





This section explains how to upgrade to DAS 3.2.0 from DAS 3.1.0. For more information on release versions, see the Release Matrix.


For information on what is new in this release and why you should upgrade, see About this Release.


You cannot roll back the upgrade process. However, it is possible to restore a backup of the previous database so that you can restart the upgrade progress.


  1. Go to the <DAS-3.2.0_HOME>/repository/conf directory and update the datasource references in the user-mgt.xml and registry.xml files to match the updated configurations in the master-datasources.xml file that you made in the above step.
    For detailed instructions to configure the user-mgt.xml file, see User Management.
    For detailed instructions to configure the registry.xml file, see Registry.
  2. Compare the configuration files in the <DAS_HOME>/repository/conf/data-bridge directory for DAS 3.1.0, and 3.2.0.
  3. Compare the configuration files in the <DAS_HOME>/repository/conf/analytics directory for DAS 3.1.0, and 3.2.0. Change the default values in DAS 3.2.0 to the same values you have specified in DAS 3.1.0.


    In DAS 3.2.0 following files are moved to <DAS_HOME>repository/conf/data directory because these runtime configuration files are required for the indexing operation. This is further explained also mentioned under Migrating indexing information.

    • my-node-id.conf

    • local-shard-allocation.conf

  4. Change the default values in <DAS_3.2.0_HOME>/repository/conf/event-processor.xml file to the same values you have specified in the <DAS_3.1.0_HOME>/repository/conf/event-processor.xml file.

    • In DAS 3.2.0, we have introduced a parameter for single-node persistence in the event-processor.xml file. The deployment mode is set to single-node deploment by default as shown below.
      <mode name="Single" enable="true"> 
      If the existing mode in DAS_3.1.0 is HA, you have to disable the Single mode and enable the HA mode in DAS_3.2.0 as shown below.
        <mode name="Single" enable="false">
      <mode name="HA" enable="true">  

    • If you enable the HA mode for WSO2 DAS by setting the <mode name="HA" enable="true"> property in the event-processor.xml file, state persistence is enabled by default. If there is no real time use case that requires any state information after starting the cluster, you should disable event persistence by setting the persistence attribute to false in the same file as shown below.

      Code Block
      <persistence enable="false">
          <persister class="org.wso2.carbon.event.processor.core.internal.persistence.FileSystemPersistenceStore">
              <property key="persistenceLocation">cep_persistence</property>

  5. Check for any other configurations that were done for DAS 3.1.0 based on your solution and update the configuration files in DAS 3.2.0 accordingly. For example, configurations related to external user stores, caching, mounting, transports etc.


Localtab Group
titleFresh setup with reindexing

All the index data and configurations are initialized when you start WSO2 DAS 3.2.0 for the first time. Therefore, if your WSO2 DAS 3.2.0 setup is a fresh setup and you want to reindex all the data after migrating analytics tables, you do not need to copy any of the indexing related configurations.

titleUsing reindexing command

This method involves running the analytics data backup/restore tool with the -reindexEvents setting to index the data. Here, the indexing is done using the existing data in the database to which you already connected WSO2 DAS 3.2.0 in the Migrating the configurations section. For more information, see Backing Up or Restoring Analytics Data.

titleCopying indexing data

Follow the steps below to migrate the index information from DAS 3.1.0 to DAS 3.2.0.

  1. Copy the contents of the <DAS_3.1.0>/repository/data directory and replace the contents of the <DAS_3.2.0>/repository/data directory with it.
  2. Take copies of the following files in the <DAS_3.1.0_HOME> and use them to replace the new files in DAS 3.2.0 that are in the locations given below.
    • <DAS-3.1.0_HOME>/repository/conf/analytics/my-node-id.dat file
      The following needs to be done when copying this file:
      1. Rename the file to datamy-node-id.dat
      2. Copy this file to the <DAS_3.2.0_HOME>/repository directory.
    • <DAS-3.1.0_HOME>/repository/conf/analytics/local-shard-allocation-config.conf file
      Copy this file to the <DAS_3.2.0_HOME>/repository/data directory.


Make sure that you do not mix the configuration files between nodes. The configuration files and index data of DAS 3.1.0 - node 1 should be copied to DAS 3.2.0 - node 1, and the configuration files and index data of DAS 3.1.0 - node 2 should be copied to DAS 3.2.0 - node 2 etc.

Migrating encrypted data
encrypted data
encrypted data

To migrate encrypted data in WSO2 DAS 3.1.0 when you upgrade to WSO2 3.2.0, follow the steps below:

  1. Download migration resources from here.
  2. Unzip the migration resources you downloaded and copy the org.wso2.das.migration-3.2.0.jar to the <DAS-3.2.0_HOME>/repository/components/dropins directory.
  3. Copy the .jks files from the <DAS-3.1.0_HOME>/repository/resources/security directory and place them in the <DAS-3.2.0_HOME>/repository/resources/security directory.
  4. Copy the .db files from the <DAS-3.1.0_HOME>/repository/database directory and place them in the <DAS-3.2.0_HOME>/repository/database directory.
  5. If you have created tenants in the WSO2 DAS 3.1.0 environment and if there are any tenant resources in the <DAS-3.1.0_HOME>/repository/tenants directory, copy that content to the <DAS-3.2.0_HOME>/repository/tenants directory.
  6. If you have created any secondary user stores in the WSO2 DAS 3.1.0 environment, copy them from the <DAS-3.1.0_HOME>/repository/deployment/server/userstores directory and place them in the <DAS-3.2.0_HOME>/repository/deployment/server/userstores directory.
  7. If you have created any event receivers and event publishers in the WSO2 DAS 3.1.0 environment, do the following:
    migrate receiver/publisher configurations
    migrate receiver/publisher configurations
    • To migrate the event receiver configurations, copy the contents in the <DAS-3.1.0_HOME>/repository/deployment/server/eventreceivers directory to the <DAS-3.2.0_HOME>/repository/deployment/server/eventreceivers directory.
    • To migrate the event publisher configurations, copy the contents in the <DAS-3.1.0_HOME>/repository/deployment/server/eventpublishers directory to the <DAS-3.2.0_HOME>/repository/deployment/server/eventpublishers directory.
  8. Start WSO2 DAS 3.2.0 with the following commend to perform data migration for encrypted data.
    • On Windows:  wso2server.bat -Dmigrate
    • On Linux/Mac OS:  sh -Dmigrate

  9. Once the migration is successfully completed, stop the server and start it again with one of the following commands.
    • On Windows:  wso2server.bat
    • On Linux/Mac OS:  sh

Migrating artifacts

All artifacts can be migrated from DAS 3.1.0 to DAS 3.2.0 via Composite Application Archive (CAR) files. For detailed instructions package artifacts as C-App archives, see Packaging Artifacts as C-App Archive.

You should manually deploy Composite Application Archive (CAR) files that you have in DAS 3.1.0 to DAS 3.2.0.


If you have already copied the configurations of one or more event receivers and/or publishers when migrating encrypted data (see Migrating encrypted data - step 7), you can exclude the configurations of those receivers and/or publishers from the CAR file.

To migrate deployment artifacts:

  • Copy the <DAS_HOME>/repository/deployment/server directory from DAS 3.1.0 to DAS 3.2.0.

  • If multi-tenancy is used, copy the <DAS_HOME>/repository/tenants directory from DAS 3.1.0 to DAS 3.2.0.


    You may have already copied the tenants directory when migrating encrypted data.

Testing the upgrade

Verify that all the required scenarios are working as expected. This confirms that the upgrade is successful.