Page Comparison

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. These instructions assume you are installing MySQL as your relational database management system (RDBMS), but you can install another supported RDBMS as needed. You can create the following databases and associated datasources.

...

1. Download and install MySQL Server.

2. Download the MySQL JDBC driver.

3. Unzip the downloaded MySQL driver zipped archive, and copy the MySQL JDBC driver JAR (mysql-connector-java-x.x.xx-bin.jar) into the <PRODUCT_HOME>/repository/components/lib directory of both the manager and worker nodes.

4. Define the host name for configuring permissions for the new database by opening the /etc/hosts file and adding the following line:
   

   <MYSQL-DB-SERVER-IP> carbondb.mysql-wso2.com

   Info
   You would do this step only if your database is not on your local machine and on a separate server.

5. Enter the following command in a terminal/command window, where username is the username you want to use to access the databases:
   mysql -u username -p
6. When prompted, specify the password that will be used to access the databases with the username you specified.

7. Create the databases using the following commands, where <PRODUCT_HOME> is the path to any of the product instances you installed, and username and password are the same as those you specified in the previous steps:

   mysql> create database WSO2_USER_DB character set latin1; mysql> use WSO2_USER_DB; mysql> source <PRODUCT_HOME>/dbscripts/mysql.sql; mysql> grant all on WSO2_USER_DB.* TO regadmin@"carbondb.mysql-wso2.com" identified by "regadmin"; mysql> create database REGISTRY_DB character set latin1; mysql> use REGISTRY_DB; mysql> source <PRODUCT_HOME>/dbscripts/

   Code Blockinfo
   language none
   title About using MySQL in different operating systems
   For users of Microsoft Window, when creating the database in MySQL, it is important to specify the character set as latin1. Failure to 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. Hence, you must use latin1 as the character set as indicated below in the database creation commands to avoid this problem. Note that this may result in issues with non-latin characters (like Hebrew, Japanese, etc.). For users of other operating systems, the standard database creation commands will suffice. mysql> create database <DATABASE_NAME>;

   Code Block
   language none
   mysql> create database WSO2_USER_DB character set latin1; mysql> use WSO2_USER_DB; mysql> source <PRODUCT_HOME>/dbscripts/mysql.sql; mysql> grant all on REGISTRYWSO2_USER_DB.* TO regadmin@"carbondb.mysql-wso2.com" identified by "regadmin"; mysql> create database REGISTRY_LOCAL1DB character set latin1; mysql> use REGISTRY_LOCAL1DB; mysql> source <PRODUCT_HOME>/dbscripts/mysql.sql; mysql> grant all on REGISTRY_LOCAL1DB.* TO regadmin@"carbondb.mysql-wso2.com" identified by "regadmin"; mysql> create database REGISTRY_LOCAL2LOCAL1 character set latin1; mysql> use REGISTRY_LOCAL2LOCAL1; mysql> source <PRODUCT_HOME>/dbscripts/mysql.sql; mysql> grant all on REGISTRY_LOCAL2LOCAL1.* TO regadmin@"carbondb.mysql-wso2.com" identified by "regadmin";
   Info
   title If you are using MySQL in Windows
   It is possible that you may encounter an error (error code: 1709) when starting your cluster using a MySQL database on Microsoft Windows. 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. In recent versions MySQL defaults to UTF-8 to be friendlier to international users. Hence, you must use latin1 as the character set as indicated above in the database creation commands to avoid this problem. Note that this may result in issues with non-latin characters (like Hebrew, Japanese, etc.). mysql> create database REGISTRY_LOCAL2 character set latin1; mysql> use REGISTRY_LOCAL2; mysql> source <PRODUCT_HOME>/dbscripts/mysql.sql; mysql> grant all on REGISTRY_LOCAL2.* TO regadmin@"carbondb.mysql-wso2.com" identified by "regadmin";

Configuring the manager node

...

• The dataSource you specify under the <dbConfig name="sharedregistry"> tag must match the jndiConfig name specified in the master-datasources.xml file of the manager and worker.
• The registry mount path is used to identify the type of registry. For example, ”/_system/config” refers to configuration registry, and "/_system/governance" refers to the governance registry.
• The dbconfig entry enables you to identify the datasource you configured in the master-datasources.xml file. We use the unique name sharedregistry to refer to that datasource entry. 
• The remoteInstance section refers to an external registry mount. We can specify the read-only/read-write nature of this instance as well as caching configurations and the registry root location. In case of a worker node, the readOnly property should be true, and in case of a manager node, this property should be set to false. 
• Additionally, we must specify cacheId, which enables caching to function properly in the clustered environment. Note that cacheId is the same as the JDBC connection URL of the registry database. This value is the cacheId of the remote instance. Here the cacheId should be in the format of $database_username@$database_url, where $database_username is the username of the remote instance database and $database_url is the remote instance database URL. This cacheID is used to identify the cache it should look for when caching is enabled. In this case, the database we should connect to is REGISTRY_DB, which is the database shared across all the master/workers nodes. You can identify that by looking in the mounting configurations, where the same datasource is being used.
• You must define a unique name “id” for each remote instance, which is then referred to from mount configurations. In the above example, the unique ID for the remote instance is instanceId. 
• In each of the mounting configurations, we specify the actual mount path and target mount path. The targetPath can be any meaningful name. In this instance, it is /_system/asNodes.

...