Skip to content

Setting Up Separate Databases for Clustering

WSO2 Identity Server uses a database to store information such as user management details and identity data. By default, each WSO2 product is shipped with an embedded H2 database that works for all types of data.

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

Embedded H2 is NOT RECOMMENDED in production

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

Before you begin

Creating separate databases as shown below is not mandatory. Instead, you can point all the following datasources accoridng to the default data structure. This will NOT make a difference in performance. For more information on default database structure, see Working with Databases.

The following image shows the default database structure and a recommended database structure for a logical separation of data.

separate-databases-for-clustering
Database Name Description
USERSTORE_DB
  • Mainly contains users and roles of the system.
  • Contains authorization manager configurations, internal permissions and roles.
  • In the default database configuration, user data and registry data are located inside SHARED_DB .
  • For more information, see Configuring User Stores.
  • IDENTITY_DB
  • Contains identity related data. For example user sessions, OAuth 2.0, SAML 2.0, User Managed Access (UMA) etc.
  • In the default database configuration, all the UMA, consent and identity data are located in the IDENTITY_DB. In a deplyment both identity and UMA can be seperated for a single database while consent data is configured to a seperate database `CONSENT_MGT`
  • For more information, see Working with Databases.
  • BPS_DB
  • This is used to create, drop, and truncate data pertaining to the workflow feature.
  • For more information, see Changing the Default Datasource for BPS.
  • SHARED_DB
  • Shared database for config and governance registry mounts in the product's nodes. This includes data on tenants and keystores.
  • In the default database configuration, user data and registry data is located inside SHARED_DB. During a deployment, user data can be configured to a different database USERSTORE_DB while registry data remains in the SHARED_DB .
  • For more information, see Working with Databases.
  • CONSENT_MGT
  • Used for data pertaining to user consents.
  • In the default database configuration, UMA, consent and identity data are located IDENTITY_DB. In a deplyment both identity and UMA can be seperated for a single database while consent data is configured to a seperate database.
  • For more information, see Changing the Default Datasource for Consent Management Database.
  • Note

    For more information on SHARED_DB and IDENTITY_DB, see Working with Databases.

    Top