This page walks you through how to manually configure the API Manager with two active nodes when deploying as an all-in-one instance.
- Unzip the WSO2 API Manager pack. Let's call it
<API-M_HOME>/repository/conf/datasources/master-datasources.xmlfile. This file contains the different datasources used by WSO2 API Manager. By default, the API Manager connects to the local H2 database and it is recommended to use a separate RDBMS server for a production deployment.
Follow the steps below to integrate the API Manager with an external database (in this case, an external MySQL Server).
- Update the existing WSO2AM_DB with the configuration given below.
Add two new entries, WSO2GOV_DB and WSO2UM_DB, as shown below.
Create the required databases.
WSO2 API Manager is shipped with an H2 database. This embedded H2 database is suitable for development and testing environments. However, for production environments, it is recommended to use an industry-standard RDBMS such as Oracle, PostgreSQL, MySQL, MS SQL, etc.
The following steps describe how to download and install MySQL Server, create the databases, configure the datasources, and configure the API Manager components to connect to them.
- Download and install MySQL Server.
- Download the MySQL JDBC driver and unzip the downloaded MySQL driver zipped archive.
- Copy the MySQL JDBC driver JAR file (
mysql-connector-java-x.x.xx-bin.jar) into the
To define the host name for configuring permissions for the new database, open the
/etc/hostsfile and add the following:
Do this step only if your database is not on your local machine and on a separate server.
Enter the following command in a command window, where username is the username you want to use to access the databases,
- When prompted, specify the password that will be used to access the databases with the username you specified.
Create the three databases using the following commands, where
<API-M_HOME>is the path to any of the API Manager instances you installed, and username and password are the same as those you specified in the previous steps.
For Microsoft Windows users: When creating the database in MySQL, it is important to specify the character set as latin1. Failure to do this may result in an error (error code: 1709) when starting your cluster. This error occurs in certain versions of MySQL (5.6.x), and is related to the UTF-8 encoding. MySQL originally used the latin1 character set by default, which stored characters in a 2-byte sequence. However, in recent versions, MySQL defaults to UTF-8 to be friendlier to international users. Therefore, in order to avoid this problem, use latin1 as the character set as indicated below in the database creation commands. Note that this may result in issues with non-latin characters (like Hebrew, Japanese, etc.). The database creation command should be as follows:
mysql> create database <DATABASE_NAME> character set latin1;
For users of other operating systems: The standard database creation commands will suffice. For these operating systems, the database creation command should be as follows:.
mysql> create database <DATABASE_NAME>;
From WSO2 Carbon Kernel 4.4.6 onwards there are two MySQL DB scripts available in the product distribution. Click here to identify as to which version of the MySQL script to use.
Configure the API Manager to refer to the WSO2UM_DB for user information by updating the following configuration in the
If you are using the
WSO2UM_DBto store users, remember to change the administrator username and password.
Start the API Manager with the following command,
This creates the required tables. Once the server starts successfully, you can shutdown it down and continue with the rest of the steps.
To add a registry entry to reflect the newly added datasource, add the following configurations to the
<API-M_HOME>/repository/conf/registry.xmlfile as shown below:
Do not replace the following configuration when adding the above mounting configurations. The registry mounting configurations mentioned above must be added in addition to the following.
<dbConfig name="wso2registry"> <dataSource>jdbc/WSO2CarbonDB</dataSource> </dbConfig>
- WSO2 API Manager is shipped with a default keystore named wso2carbon.jks. It is recommended to change this default keystore in a production deployment. For more information on changing this default keystore, see Creating New Keystores.
A load balancer or reverse proxy is required to map external traffic with ports and URLs used internally by API Manager.
ngnix.conffile with the required Nginx configuration given below. In this case, the hostname is assumed to be
localhost. Ensure that you generate a certificate and update the certificate and key path in the configuration below:
The ports and URLs that are used internally by API Manager are given below:
HTTPS Servlet (UI Consoles)
NIO transport (HTTP API Traffic)
NIO transport (HTTPS API Traffic)
Ensure that the ports and URLs are mapped correctly in the load balancer.
In a Active-Active setup, It is mandatory to set up Session Affinity in the load balancers that front the Publisher and Store, and it is optional in the load balancer (if any) that fronts Key Manager or Gateway.
However, authentication via session ID fails when Session Affinity is disabled in the load balancers of Publisher and store.
Follow the steps below to update the API Store, API Publisher and Admin Portal to work with the Proxy Server configuration.
API Store - Update the
<API-M_Home>\repository\deployment\server\jaggeryapps\store\site\conf\site.jsonfile as shown below:
API Publisher - Update the
<API-M_Home>\repository\deployment\server\jaggeryapps\publisher\site\conf\site.jsonfile as shown below:
Admin Portal - Update the
<API-M_Home>\repository\deployment\server\jaggeryapps\admin\site\conf\site.jsonfile as shown below:
Make a copy of the active instance configured above. Use this copy as the second active instance.
- Follow the steps below to enable clustering to ensure that each node is in sync with the changes that happen to the other node.
<API-M_HOME>/repository/conf/axis2/axis2.xmlfile and set the
enableattribute of the
trueas shown below,
wkaas shown below,
Provide a domain for the cluster as shown below,
localMemberHostshould be the server's IP address. The port value should be the port on which the server will be listening for incoming cluster messages. If you are running the API Manager nodes on the same machine, you require two different
Specify a well known member. When specifying the well known member, the primary active node should specify the information of the secondary active node and vice versa. The port you provide here should be the same as the
localMemberPortof the other member.
- Save and close the file and restart the servers (if running) for the changes to take effect.
Configure the API Publisher of both nodes to publish to the Gateway of one of the nodes by pointing the
<ServerURL>to the same Gateway node.
- You require a content synchronization mechanism like Rsync to synchronize the artifacts in the
<API-M_HOME>/repository/deployment/server/synapse-configsdirectory of one node with those of the other node. To set up an Rsync based deployment synchronization, see Configuring Rsync for Deployment Synchronization.
You need to configure the Traffic Manager of each node to be able to publish events to the Traffic Manager of the other node. Let's create an additional JNDI config file, namely
jndi2.properties, in both the nodes as shown below,
Add the configuration given below to the JNDI properties file that you just created. Assuming that you are running both API Managers nodes on the same server, the 2nd API Manager node would be running with a port offset of 1. Therefore, the port is given as 5673 below.
- Let's create a new JMS Event Publisher by creating a file (for example,
jmsEventPublisher2.xml) in the
<API-M_HOME>\repository\deployment\server\eventpublishersdirectory of each of the two nodes.
Add the configuration given below to the JMSEventPublisher file found in both of the nodes. Note that you refer to the JNDI properties file that you created above in the configuration shown below.
- Save your changes.