MariaDB Galera Database Configuration
This section documents the supported Galera Cluster configuration for MariaDB. Both server and client need to be configured correctly. Please note that there are some known limitations which apply when using Galera cluster, see below.
Please note that server and client configuration settings defined below are the only configuration that is supported for Galera Cluster. Other configurations are not supported.
The following configuration needs to go into the
[galera] configuration section in the
my.cnf.d/server.cnf on each server:
[galera] binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 transaction-isolation=READ-COMMITTED wsrep_on=ON wsrep_causal_reads = 1 wsrep_sync_wait = 7 ...
Note that other setting may be present in this section but the settings
wsrep_sync_wait need to present and need to have exactly the values shown above.
sequential configurations are supported. Other client configuration modes like
aurora: are not supported.
The following is the required format of the jdbcUrl property in datasource configurations:
Important: when running Camunda in a cluster, the client configuration needs to be the same on each node.
Galera Cluster Known Limitations
The following known limitations apply when using Galera Cluster:
- APIs requiring Pessimistic read locks in the database do not work correctly. Affected APIs: Exclusive Message correlation (
.correlateExclusively()). See (Javadocs ). Another possible negative effects:
- duplication of deployed definitions when deploying the same resources from two threads simultaneously
- duplication of history cleanup job when calling
HistoryService#cleanUpHistoryAsyncfrom two threads simultaneously
- Duplicate checking during deployment does not work if resources are deployed in a cluster concurrently. Concrete impact: suppose there is a Camunda process engine cluster which connects to the same Galera cluster. On deployment of a new process application the process engine nodes will check if the BPMN processes provided by the process application are already deployed, to avoid duplicate deployments. If the deployment is done simultaneously on multiple process engine nodes an exclusive read lock is acquired on the the database (technically, this means that each node performs an SQL
select for updatequery.), to do the duplicate checking reliably under concurrency. This does not work on Galera Cluster and may lead to multiple versions of the same process being deployed.
jdbcStatementTimeoutconfiguration setting does not work and cannot be used.