Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 data sources:

...

    • 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.
    • This configuration enables you to identify the data source you configured in the master-datasources.xml file using the dbConfig entry and we give a unique name to refer to that datasource entry which is “sharedregistry”. 
    • 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 need to specify cacheId for caching to function properly in the clustered environment. Note that cacheId is same as the JDBC connection URL to our 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_DBwhich 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 need to define a unique name “id” for each remote instance which is then referred 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.

...

Now your database is set up. The next step is to configure the manager and worker node.

Excerpt
hiddentrue

All This topic encompasses all configurations related to creating and setting up databases for the products in your cluster are found in this topic. This includes configurations you would have to make in both the manager node and the worker node.