Setting Up Separate Databases for Clustering

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 /wiki/spaces/IS570/pages/38175102 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 Name	Description	Script location	Datasource file to be modified
`WSO2_USER_DB`	Authorization manager configurations, internal permissions and roles.	<PRODUCT_HOME>/dbscripts/	`<PRODUCT_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_DB`	Contains identity related data. For example, OAuth 2.0, SAML 2.0, user managed access (UMA) etc.	<PRODUCT_HOME>/dbscripts/identity/ UMA related scripts are in the `<PRODUCT_HOME>/dbscripts/identity/uma` directory. You can run the scripts to create the UMA related tables and indexes in the IDENTITY_DB.	`<PRODUCT_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_DB`	Metrics 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.	<PRODUCT_HOME>/dbscripts/metrics/	`<PRODUCT_HOME>/repository/conf/datasources/metrics-datasources.xml`
`BPS_DB`	This 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 `<PRODUCT_HOME>/dbscripts/bps/bpel/create` directory. To delete workflow related tables, use the scripts in the `<PRODUCT_HOME>/dbscripts/bps/bpel/drop` directory. To remove workflow related data from tables, use the scripts in the `<PRODUCT_HOME>/dbscripts/bps/bpel/truncate` directory.	`<PRODUCT_HOME>/repository/conf/datasources/bps-datasources.xml`
`REGISTRY_DB`	Shared database for config and governance registry mounts in the product's nodes. This includes data on tenants and keystores.	<PRODUCT_HOME>/dbscripts/	`<PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml`
`CONSENT_MGT`	This is used for data pertaining to user consents.	`<PRODUCT_HOME>/dbscripts/consent`	`<PRODUCT_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` 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.