The following steps describe how to download and install a RDBMS, which in this case is a MySQL Server, create the databases, configure the data sources, and configure the WSO2 Identity Server (WSO2 IS) components to connect to them.
Although the following section instructs you to use MySQL Server, you can use any RDBMS in your deployment based on your preference. For information on working with other databases, see Changing the Default API-M Databases.
The steps involved in installing and configuring the databases are the same irrespective of whether you are using a single node (standalone) deployment, an active-active deployment, or a distributed deployment.
Download the MySQL JDBC driver.
Unzip the downloaded MySQL driver archive, and copy the MySQL JDBC driver JAR (
mysql-connector-java-x.x.xx-bin.jar) into the
<IS_HOME>/repository/components/libdirectory in all the nodes in the cluster where
<IS_HOME>refers to the location of the extracted WSO2 Identity Server (WSO2 IS) distribution.
Define the hostname for configuring permissions for the new database by opening the
/etc/hostsfile and adding the following:
Do this step only if your database is not on your local machine and on a separate server.
Install mysql-client in each of the Identity Server nodes in which WSO2 Identity Server is deployed.
You need to do this in order to check if the servers can access the MySQL database.
Enter the following command in a command prompt, where
usernameis the username that you used to access the databases.
When prompted, specify the password that will be used to access the databases with the username you specified.
When setting up WSO2 Identity Server (WSO2 IS) as the key manager, you need to work with the user (
userdb) and registry (
regdb) databases; however, as the latter mentioned two databases are databases that you have already created and setup for WSO2 API Manager (WSO2 API-M), you do not need to create the latter mentioned databases again.
Configure the data sources for the user (
userdb) and the registry (
regdb) databases as follows in the
This file contains the different datasources used by WSO2 Identity Server. By default, the Identity Server connects to the local H2 database and it is recommended to use a separate RDBMS for a production deployment.
For more information, see Configuring master-datasources.xml in the Administration Guide.
Note: When configuring clustering, ignore the
WSO2_CARBON_DBdata source configuration.
Enable the components to access the WSO2 API Manager database by changing the URL as indicated below. Make sure to replace
db.mysql-wso2.comwith the hostname you specified in step 5 (
carbondb.mysql-wso2.com) in the
Enable the Key Manager to access the user management database.
You need to do this by adding the following code and changing the
carbondb.mysql-wso2.comin order to configure the
Enable the Key Manager to have access to registry databases by adding the following
WSO2REG_DBdata source related configuration.
This is only applicable in a multi-tenanted environment.
Make the following changes in the
To give the Key Manager component access with shared permissions to the user management database, add or modify the
dataSourceproperty that corresponds to the
<configuration>element as follows so that it points to the
WSO2UM_DBdatabase. By default, this configuration points to the embedded H2 database.
This is only applicable in a multi-tenanted environment.
Make sure you add the user store configuration correctly so that both the WSO2 Identity Server and WSO2 API Manager server point to the same user store. For more information, see Configuring User Stores in the Administration Guide.
You must change the
<UserStoreManager>element here as the internal LDAP user store is used by default. You need to remove or modify the
<UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager">code block with the correct LDAP that you are using. You could alternatively use the embedded LDAP in the WSO2 Identity Server as your user store. For more information, see Configuring the Primary User Store in the Administration Guide.
If you are using the
WSO2UM_DBto store users, remember to change the administrator's username and password. For more information, see Maintaining Logins and Passwords.
To enable the Key Manager to access to the registry database, open the
<IS_HOME>/repository/conf/registry.xmlfile in the Key Manager node and add or modify the
dataSourceattribute of the
<dbConfig name="govregistry">element as follows in order to mount the Key Manager to the governance registry space.
For more information on the properties and values related to the remote mount configurations, see Configuring registry.xml in the Administration Guide.
Note that this is only applicable in a multi-tenanted environment.
Do not replace the following configuration when adding in the mounting configurations mentioned below. The registry mounting configurations mentioned in the following steps must be added beneath the following entry, which is already in the configuration file.
This configuration is related to the local H2 DB, which is used to store the mount information, indexing configuration and anything local to the node, and hence should not be removed even if separate governance and config registries are used.
CacheIdis a unique identification of the remote instance. When you configure the remote instance, WSO2 recommends that you modify the
<cacheId>with the corresponding values of your setup, based on the following format :
You do not need to specify the
remoteInstanceURL in the above configuration, because WS mounting in not used in WSO2 API-M 2.1.0 onward.
In the above code snippet the governance registry and the config registry are pointed to the same database. If required, you can use two databases for the two registries that are shared with Key Manager nodes.