This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

This section guides you through the logical separation of data that you can do when clustering WSO2 Identity Server. 

Before you begin

Before you begin, note that creating separate databases as shown below is not actually required and can be skipped. Instead, you can point all the datasources given below to a single database. This will NOT make a difference in performance. To do this, see the steps given within the flow of the deployment pattern setup in the Configuring the datasources sub topic.

However, if you do want to separate the data logically into separate databases, you can follow the steps given below.

Each Carbon-based product uses a database to store information such as user management details and registry data. All nodes in the cluster must use one central database for config and governance registry mounts. By default, each WSO2 product is shipped with an embedded H2 database that works for all types of data. 

Embedded H2 is not recommended in production

The embedded H2 database is NOT recommended in enterprise testing and production environments. It has lower performance, clustering limitations, and can cause file corruption failures. Please use an industry-standard RDBMS such as Oracle, PostgreSQL, MySQL, or MS SQL instead.

You can use the embedded H2 database in development environments and as the local registry in a registry mount. However, in a production environment it is recommended to change this. For more information on how to do this, set up the database and see the Changing the Carbon Database topic in the product administration guide.

You can create the following databases and associated datasources. This is NOT mandatory and you can choose to not create these databases if you wish and simply have a single database to handle all these concerns.

Database NameDescriptionScript locationDatasource file to be modified
USERSTORE_DBAuthorization manager configurations, internal permissions and roles.
<IS_HOME>/dbscripts/

<IS_HOME>/repository/conf/datasources/master-datasources.xml

The data source name mentioned in the master-datasources.xml file should be included in the user-mgt.xml file in <PRODUCT_HOME>/repository/conf/ as well.
IDENTITY_DBContains identity related data, for example, OAuth 2.0, SAML 2.0, etc.
<IS_HOME>/dbscripts/identity/

<IS_HOME>/repository/conf/datasources/master-datasources.xml

The data source name mentioned in the master-datasources.xml file should be included in the identity.xml file in <PRODUCT_HOME>/repository/conf/identity as well.
METRICS_DBMetrics Database is used to store the runtime metrics data reported by the Metrics JDBC Reporter periodically. There are 5 tables to store metrics data for each metric type. The metric types are Counter, Meter, Gauge, Histogram, and Timer.
<IS_HOME>/dbscripts/metrics/
<IS_HOME>/repository/conf/datasources/metrics-datasources.xml
BPS_DBThis is used to create, drop, and truncate data pertaining to the workflow feature.
  • To create workflow related tables and indexes, use the scripts in the <IS_HOME>/dbscripts/bps/bpel/create directory.
  • To delete workflow related tables, use the scripts in the <IS_HOME>/dbscripts/bps/bpel/drop directory.
  • To remove workflow related data from tables, use the scripts in the <IS_HOME>/dbscripts/bps/bpel/truncate directory.
<IS_HOME>/repository/conf/datasources/bps-datasources.xml
REGISTRY_DBShared database for config and governance registry mounts in the product's nodes. This includes data on tenants and keystores.
<IS_HOME>/dbscripts/
<IS_HOME>/repository/conf/datasources/master-datasources.xml
CONSENT_MGTThis is used for data pertaining to user consents.<IS_HOME>/dbscripts/consent

<IS_HOME>/repository/conf/datasources/master-datasources.xml

The data source name mentioned in the master-datasources.xml file should be included in the consent-mgt-config.xml file in <PRODUCT_HOME>/repository/conf/ as well.

To understand this concept further, see the following diagram.

For more information on the concept of sharing governance and config registry databases across the cluster, see the topic on Sharing Databases in a Cluster in the WSO2 Product Administration Guide.

Do the following configurations to implement the database setup.

Creating the databases

Create the databases that you require using the RDBMS of your choice and run the relevant script for the RDBMS of your choice according to the table above. For instructions on how to do this, see Setting up the Physical Database in the WSO2 Product Administration Guide.

Configuring the datasources

Configure the datasources for the databases that you created above in both the WSO2 Identity Server nodes of your cluster. For instructions on how to configure the datasources for the databases you created, see Changing the Carbon Database in the WSO2 Product Administration Guide.

  • No labels