MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Висока достъпност на базата данни за Camunda BPM с помощта на MySQL или MariaDB Galera Cluster

Camunda BPM е платформа за автоматизация на работния процес и вземането на решения с отворен код. Camunda BPM се доставя с инструменти за създаване на работни процеси и модели за вземане на решения, опериране на внедрените модели в производството и позволява на потребителите да изпълняват задачи на работния процес, възложени им.

По подразбиране Camunda идва с вградена база данни, наречена H2, която работи доста прилично в среда на Java със сравнително малък отпечатък на паметта. Въпреки това, когато става въпрос за мащабиране и висока наличност, има други бекендове на базата данни, които може да са по-подходящи.

В тази публикация в блога ще внедрим Camunda BPM 7.10 Community Edition на Linux, с фокус върху постигането на висока достъпност на базата данни. Camunda поддържа основни бази данни чрез JDBC драйвери, а именно Oracle, DB2, MySQL, MariaDB и PostgreSQL. Този блог се фокусира само върху MySQL и MariaDB Galera Cluster, с различна реализация на всеки - единият с ProxySQL като балансьор на натоварване на базата данни, а другият използва JDBC драйвера за свързване към множество екземпляри на база данни. Обърнете внимание, че тази статия не обхваща високата наличност за самото приложение Camunda.

Предварително условие

Camunda BPM работи на Java. В нашата кутия CentOS 7 трябва да инсталираме JDK и най-добрият вариант е да използваме този от Oracle и да пропуснем използването на пакетите OpenJDK, предоставени в хранилището. На сървъра на приложения, където трябва да работи Camunda, изтеглете най-новия комплект за разработка на Java SE (JDK) от Oracle, като изпратите бисквитката за приемане:

$ wget --header "Cookie: oraclelicense=accept-securebackup-cookie" https://download.oracle.com/otn-pub/java/jdk/12+33/312335d836a34c7c8bba9d963e26dc23/jdk-12_linux-x64_bin.rpm

Инсталирайте го на хоста:

$ yum localinstall jdk-12_linux-x64_bin.rpm

Потвърдете с:

$ java --version
java 12 2019-03-19
Java(TM) SE Runtime Environment (build 12+33)
Java HotSpot(TM) 64-Bit Server VM (build 12+33, mixed mode, sharing)

Създайте нова директория и изтеглете Camunda Community за Apache Tomcat от официалната страница за изтегляне:

$ mkdir ~/camunda
$ cd ~/camunda
$ wget --content-disposition 'https://camunda.org/release/camunda-bpm/tomcat/7.10/camunda-bpm-tomcat-7.10.0.tar.gz'

Извлечете го:

$ tar -xzf camunda-bpm-tomcat-7.10.0.tar.gz

Има редица зависимости, които трябва да конфигурираме, преди да стартираме уеб приложението Camunda. Това зависи от избраната платформа за база данни, като конфигурация на хранилище за данни, конектор за база данни и среда CLASSPATH. Следващите раздели обясняват необходимите стъпки за MySQL Galera (използвайки Percona XtraDB Cluster) и MariaDB Galera Cluster.

Имайте предвид, че конфигурациите, показани в този блог, са базирани на средата на Apache Tomcat. Ако използвате JBOSS или Wildfly, конфигурацията на хранилището за данни ще бъде малко по-различна. Вижте документацията на Camunda за подробности.

MySQL Galera Cluster (с ProxySQL и Keepalived)

Ще използваме ClusterControl за разгръщане на MySQL-базиран клъстер Galera с Percona XtraDB Cluster. Има някои ограничения, свързани с Galera, споменати в документите на Camunda, свързани с обработката на конфликти с множество записвания на Galera и нивото на изолация на InnoDB. В случай, че сте засегнати от тях, най-сигурният начин е да използвате подхода с единичен запис, който е постижим с конфигурацията на хостгрупата на ProxySQL. За да не осигурим единична точка на отказ, ще разположим две копия на ProxySQL и ще ги свържем с виртуален IP адрес от Keepalived.

Следната диаграма илюстрира нашата окончателна архитектура:

Първо, разгърнете Percona XtraDB Cluster с три възли 5.7. Инсталирайте ClusterControl, генерирайте SSH ключ и настройте SSH без парола от хоста на ClusterControl към всички възли (включително ProxySQL). На възела ClusterControl направете:

$ whoami
root
$ ssh-keygen -t rsa
$ for i in 192.168.0.21 192.168.0.22 192.168.0.23 192.168.0.11 192.168.0.12; do ssh-copy-id $i; done

Преди да разположим нашия клъстер, трябва да модифицираме файла с шаблон за конфигурация на MySQL, който ClusterControl ще използва при инсталиране на MySQL сървъри. Името на файла на шаблона е my57.cnf.galera и се намира под /usr/share/cmon/templates/ на хоста на ClusterControl. Уверете се, че в секцията [mysqld] съществуват следните редове:

[mysqld]
...
transaction-isolation=READ-COMMITTED
wsrep_sync_wait=7
...

Запазете файла и сме готови. По-горе са изискванията, посочени в документите на Camunda, особено относно поддържаната изолация на транзакции за Galera. Променливата wsrep_sync_wait е настроена на 7 за извършване на проверки за причинно-следствена връзка в целия клъстер за READ (включително SELECT, SHOW и BEGIN или START TRANSACTION), UPDATE, DELETE, INSERT и REPLACE, като се гарантира, че операторът се изпълнява на напълно синхронизиран възел. Имайте предвид, че стойност, различна от 0, може да доведе до увеличаване на латентността.

Отидете на ClusterControl -> Разгръщане -> MySQL Galera и посочете следните подробности (ако не са споменати, използвайте стойността по подразбиране):

  • SSH потребител:root
  • SSH ключов път:/root/.ssh/id_rsa
  • Име на клъстер:Percona XtraDB Cluster 5.7
  • Продавач:Percona
  • Версия:5.7
  • Парола за администратор/Root:{посочете парола
  • Добавяне на възел:192.168.0.21 (натиснете Enter), 192.168.0.22 (натиснете Enter), 192.168.0.23 (натиснете Enter)

Уверете се, че сте получили всички зелени отметки, което показва, че ClusterControl може да се свърже с възела без парола. Щракнете върху „Разгръщане“, за да започнете внедряването.

Създайте базата данни, MySQL потребител и парола на един от възлите на базата данни:

mysql> CREATE DATABASE camunda;
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql> GRANT ALL PRIVILEGES ON camunda.* TO [email protected]'%';

Или от интерфейса на ClusterControl можете да използвате Управление -> Схема и потребители вместо това:

След като клъстерът бъде разгърнат, инсталирайте ProxySQL, като отидете на ClusterControl -> Manage -> Load Balancer -> ProxySQL -> Deploy ProxySQL и въведете следните данни:

  • Адрес на сървъра:192.168.0.11
  • Административна парола:
  • Парола за наблюдение:
  • Потребител на DB:camunda
  • Парола за DB:passw0rd
  • Използвате ли неявни транзакции?:Да

Повторете стъпката за внедряване на ProxySQL за втория екземпляр на ProxySQL, като промените адреса на сървъра стойност до 192.168.0.12. Виртуалният IP адрес, предоставен от Keepalived, изисква поне две разгърнати и работещи копия на ProxySQL. И накрая, внедрете виртуален IP адрес, като отидете на ClusterControl -> Manage -> Load Balancer -> Keepalived и изберете двата възела на ProxySQL и посочете виртуалния IP адрес и мрежовия интерфейс, който VIP да слуша:

Нашата база данни е завършена. След това импортирайте SQL файловете в клъстера Galera като създаден потребител на MySQL. На сървъра на приложения отидете в директорията "sql" и ги импортирайте в един от възлите на Galera (избираме 192.168.0.21):

$ cd ~/camunda/sql/create
$ yum install mysql #install mysql client
$ mysql -ucamunda -p -h192.168.0.21 camunda < mysql_engine_7.10.0.sql
$ mysql -ucamunda -p -h192.168.0.21 camunda < mysql_identity_7.10.0.sql

Camunda не предоставя MySQL конектор за Java, тъй като неговата база данни по подразбиране е H2. На сървъра на приложения изтеглете MySQL Connector/J от страницата за изтегляне на MySQL и копирайте JAR файла в директорията bin Apache Tomcat:

$ wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-8.0.15.tar.gz
$ tar -xzf mysql-connector-java-8.0.15.tar.gz
$ cd mysql-connector-java-8.0.15
$ cp mysql-connector-java-8.0.15.jar ~/camunda/server/apache-tomcat-9.0.12/bin/

След това задайте променливата на средата CLASSPATH да включва конектора на базата данни. Отворете setenv.sh с текстов редактор:

$ vim ~/camunda/server/apache-tomcat-9.0.12/bin/setenv.sh

И добавете следния ред:

export CLASSPATH=$CLASSPATH:$CATALINA_HOME/bin/mysql-connector-java-8.0.15.jar

Отворете ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml и променете редовете, свързани с хранилището на данни. Посочете виртуалния IP адрес като MySQL хост в низа за връзка с ProxySQL порт 6033:

<Resource name="jdbc/ProcessEngine"
              ...
              driverClassName="com.mysql.jdbc.Driver" 
              defaultTransactionIsolation="READ_COMMITTED"
              url="jdbc:mysql://192.168.0.10:6033/camunda"
              username="camunda"  
              password="passw0rd"
              ...
/>

И накрая, можем да стартираме услугата Camunda, като изпълним start-camunda.sh скрипт:

$ cd ~/camunda
$ ./start-camunda.sh
starting camunda BPM platform on Tomcat Application Server
Using CATALINA_BASE:   ./server/apache-tomcat-9.0.12
Using CATALINA_HOME:   ./server/apache-tomcat-9.0.12
Using CATALINA_TMPDIR: ./server/apache-tomcat-9.0.12/temp
Using JRE_HOME:        /
Using CLASSPATH:       :./server/apache-tomcat-9.0.12/bin/mysql-connector-java-8.0.15.jar:./server/apache-tomcat-9.0.12/bin/bootstrap.jar:./server/apache-tomcat-9.0.12/bin/tomcat-juli.jar
Tomcat started.

Уверете се, че CLASSPATH, показан в изхода, включва пътя към MySQL Connector/J JAR файла. След като инициализацията приключи, можете да получите достъп до уеб приложенията на Camunda на порт 8080 на адрес http://192.168.0.8:8080/camunda/ . Потребителското име по подразбиране е демонстрация с парола 'demo':

След това можете да видите обобщените заявки за улавяне от Nodes -> ProxySQL -> Top Queries , което показва, че приложението взаимодейства правилно с клъстера Galera:

Няма конфигурирано разделяне за четене и запис за ProxySQL. Camunda използва "SET autocommit=0" за всеки SQL оператор, за да инициализира транзакцията и най-добрия начин за ProxySQL да се справи с това, като изпрати всички заявки към едни и същи бекенд сървъри на целевата хост група. Това е най-безопасният метод наред с по-добрата наличност. Въпреки това, всички връзки може да достигнат до един сървър, така че няма балансиране на натоварването.

MariaDB Galera

MariaDB Connector/J може да се справи с различни режими на свързване - отказ, последователен, репликация и аврора - но Camunda поддържа само отказ и последователен. Взето от документацията на MariaDB Connector/J:

Режим Описание
последователно
(достъпно от 1.3.0)
Този режим поддържа преодоляване на връзката при отказ в среда с няколко главни, като например MariaDB Galera Cluster. Този режим не поддържа четене за балансиране на натоварването на подчинени устройства. Конекторът ще се опита да се свърже с хостове в реда, в който са били декларирани в URL адреса на връзката, така че първият наличен хост се използва за всички заявки. Например, да кажем, че URL адресът на връзката е следният:
jdbc:mariadb:sequential:host1,host2,host3/testdb
Когато конекторът се опита да се свърже, той винаги първо ще пробва host1. Ако този хост не е наличен, той ще опита host2. и т.н. Когато даден хост се повреди, конекторът ще се опита да се свърже отново с хостове в същия ред.
отказ
(достъпно от 1.2.0)
Този режим поддържа преодоляване на връзката при отказ в среда с няколко главни, като например MariaDB Galera Cluster. Този режим не поддържа четене за балансиране на натоварването на подчинени устройства. Конекторът извършва балансиране на натоварването за всички заявки, като избира хост от URL адреса на връзката за всяка връзка, така че заявките ще бъдат балансирани в резултат на произволно разпределение на връзките между всички хостове.

Използването на режим „отказ при отказ“ представлява по-висок потенциален риск от блокиране, тъй като записите ще бъдат разпределени до всички сървъри на бекенда почти еднакво. Подходът с единичен запис е безопасен начин за изпълнение, което означава, че използването на последователен режим трябва да свърши работата доста добре. Можете също да пропуснете нивото на балансиране на натоварването в архитектурата. Следователно с конектора на MariaDB Java можем да внедрим нашата архитектура толкова проста, колкото по-долу:

Преди да разположим нашия клъстер, модифицирайте файла с шаблон за конфигурация на MariaDB, който ClusterControl ще използва при инсталиране на сървъри на MariaDB. Името на файла на шаблона е my.cnf.galera и се намира под /usr/share/cmon/templates/ на хоста на ClusterControl. Уверете се, че в секцията [mysqld] съществуват следните редове:

[mysqld]
...
transaction-isolation=READ-COMMITTED
wsrep_sync_wait=7
performance_schema = ON
...

Запазете файла и сме готови. Малко обяснение, горният списък са изискванията, както е посочено в документите на Camunda, особено относно поддържаната изолация на транзакции за Galera. Променливата wsrep_sync_wait е настроена на 7 за извършване на проверки за причинно-следствена връзка в целия клъстер за READ (включително SELECT, SHOW и BEGIN или START TRANSACTION), UPDATE, DELETE, INSERT и REPLACE, като се гарантира, че операторът се изпълнява на напълно синхронизиран възел. Имайте предвид, че стойност, различна от 0, може да доведе до увеличаване на латентността. Активирането на схемата на производителност не е задължително за функцията за наблюдение на заявки на ClusterControl.

Сега можем да започнем процеса на разгръщане на клъстер. Инсталирайте ClusterControl, генерирайте SSH ключ и настройте SSH без парола от хоста на ClusterControl към всички възли на Galera. На възела ClusterControl направете:

$ whoami
root
$ ssh-keygen -t rsa
$ for i in 192.168.0.41 192.168.0.42 192.168.0.43; do ssh-copy-id $i; done

Отидете на ClusterControl -> Разгръщане -> MySQL Galera и посочете следните подробности (ако не са споменати, използвайте стойността по подразбиране):

  • SSH потребител:root
  • SSH ключов път:/root/.ssh/id_rsa
  • Име на клъстер:MariaDB Galera 10.3
  • Доставчик:MariaDB
  • Версия:10.3
  • Парола за администратор/Root:{посочете парола
  • Добавяне на възел:192.168.0.41 (натиснете Enter), 192.168.0.42 (натиснете Enter), 192.168.0.43 (натиснете Enter)

Уверете се, че сте получили всички зелени отметки при добавяне на възли, което показва, че ClusterControl може да се свърже с възела без парола. Щракнете върху „Разгръщане“, за да започнете внедряването.

Създайте базата данни, потребител на MariaDB и парола на един от възлите на Galera:

mysql> CREATE DATABASE camunda;
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql> GRANT ALL PRIVILEGES ON camunda.* TO [email protected]'%';

За потребител на ClusterControl можете да използвате ClusterControl -> Управление -> Схема и потребители вместо това:

Разгръщането на клъстер от база данни вече е завършено. След това импортирайте SQL файловете в клъстера MariaDB. На сървъра на приложения отидете в директорията "sql" и ги импортирайте в един от възлите на MariaDB (избрахме 192.168.0.41):

$ cd ~/camunda/sql/create
$ yum install mysql #install mariadb client
$ mysql -ucamunda -p -h192.168.0.41 camunda < mariadb_engine_7.10.0.sql
$ mysql -ucamunda -p -h192.168.0.41 camunda < mariadb_identity_7.10.0.sql

Camunda не предоставя конектор MariaDB за Java, тъй като неговата база данни по подразбиране е H2. На сървъра на приложения изтеглете MariaDB Connector/J от страницата за изтегляне на MariaDB и копирайте JAR файла в Apache Tomcat bin директория:

$ wget https://downloads.mariadb.com/Connectors/java/connector-java-2.4.1/mariadb-java-client-2.4.1.jar
$ cp mariadb-java-client-2.4.1.jar ~/camunda/server/apache-tomcat-9.0.12/bin/

След това задайте променливата на средата CLASSPATH да включва конектора на базата данни. Отворете setenv.sh чрез текстов редактор:

$ vim ~/camunda/server/apache-tomcat-9.0.12/bin/setenv.sh

И добавете следния ред:

export CLASSPATH=$CLASSPATH:$CATALINA_HOME/bin/mariadb-java-client-2.4.1.jar

Отворете ~/camunda/server/apache-tomcat-9.0.12/conf/server.xml и променете редовете, свързани с хранилището на данни. Използвайте протокола за последователно свързване и избройте всички възли на Galera, разделени със запетая в низа за връзка:

<Resource name="jdbc/ProcessEngine"
              ...
              driverClassName="org.mariadb.jdbc.Driver" 
              defaultTransactionIsolation="READ_COMMITTED"
              url="jdbc:mariadb:sequential://192.168.0.41:3306,192.168.0.42:3306,192.168.0.43:3306/camunda"
              username="camunda"  
              password="passw0rd"
              ...
/>

И накрая, можем да стартираме услугата Camunda, като изпълним start-camunda.sh скрипт:

$ cd ~/camunda
$ ./start-camunda.sh
starting camunda BPM platform on Tomcat Application Server
Using CATALINA_BASE:   ./server/apache-tomcat-9.0.12
Using CATALINA_HOME:   ./server/apache-tomcat-9.0.12
Using CATALINA_TMPDIR: ./server/apache-tomcat-9.0.12/temp
Using JRE_HOME:        /
Using CLASSPATH:       :./server/apache-tomcat-9.0.12/bin/mariadb-java-client-2.4.1.jar:./server/apache-tomcat-9.0.12/bin/bootstrap.jar:./server/apache-tomcat-9.0.12/bin/tomcat-juli.jar
Tomcat started.

Уверете се, че CLASSPATH, показан в изхода, включва пътя до JAR файла на клиента на Java на MariaDB. След като инициализацията приключи, можете да получите достъп до уеб приложенията на Camunda на порт 8080 на адрес http://192.168.0.8:8080/camunda/ . Потребителското име по подразбиране е демонстрация с парола 'demo':

Можете да видите обобщените заявки за улавяне от ClusterControl -> Монитор на заявки -> Най-популярни заявки , което показва, че приложението взаимодейства правилно с клъстера MariaDB:

С MariaDB Connector/J нямаме нужда от ниво на балансиране на натоварването, което опростява цялостната ни архитектура. Режимът на последователно свързване трябва да свърши работа, за да избегне блокиране на множество записвания - което може да се случи в Galera. Тази настройка осигурява висока наличност с всеки екземпляр на Camunda, конфигуриран с JDBC, за достъп до клъстера от MySQL или MariaDB възли. Galera се грижи за синхронизирането на данните между екземплярите на базата данни в реално време.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MariaDB SYSTEM_USER() Обяснено

  2. Как работи UTC_TIMESTAMP() в MariaDB

  3. 4 начина да получите съпоставяне на база данни в MariaDB

  4. Как REGEXP_INSTR() работи в MariaDB

  5. MySQL срещу MariaDB срещу Percona Server:Сравнение на функциите за сигурност