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 Name | Description | Script location | Datasource file to be modified |
|---|---|---|---|
USERSTORE_DB | Authorization manager configurations, internal permissions and roles. | <PRODUCT_HOME>/dbscripts/ |
Note that the corresponding data source name mentioned in the master-datasources.xml file should be included in |
IDENTITY_DB | Contains identity related data, for example, OAuth 2.0, SAML 2.0, etc. | <PRODUCT_HOME>/dbscripts/identity/ |
Note that the data source name mentioned in the master data source should be included in |
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 for data pertaining to the workflow feature. | <PRODUCT_HOME>/dbscripts/ | <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 |
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.