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

Как да замените междинен MySQL или MariaDB Master с Binlog сървър с помощта на MaxScale

Двоичните регистрационни файлове (binlogs) съдържат записи за всички промени в базите данни. Те са необходими за репликация и могат да се използват и за възстановяване на данни след архивиране. Сървърът на binlog е основно хранилище за двоични регистрационни файлове. Можете да го мислите като сървър със специална цел за извличане на двоични регистрационни файлове от главен, докато подчинените сървъри могат да се свързват с него, както биха се свързали с главен сървър.

Някои предимства от наличието на binlog сървър пред междинния главен за разпределяне на натоварването за репликация са:

  • Можете да преминете към нов главен сървър, без подчинените да забележат, че действителният главен сървър се е променил. Това позволява по-достъпна настройка за репликация, където репликацията е с висок приоритет.
  • Намалете натоварването на главния, като обслужвате само binlog сървъра на Maxscale вместо всички подчинени.
  • Данните в двоичния регистър на междинния главен файл не са директно копие на данните, получени от двоичния дневник на истинския главен. Като такъв, ако се използва групов комит, това може да доведе до намаляване на паралелизма на комитациите и последващо намаляване на производителността на подчинените сървъри.
  • Междинното подчинено устройство трябва да изпълни повторно всеки SQL израз, което потенциално добавя латентност и изостава във веригата на репликация.

В тази публикация в блога ще разгледаме как да заменим междинен главен (подчинен хост реле към други подчинени устройства във веригата за репликация) с binlog сървър, работещ на MaxScale за по-добра мащабируемост и производителност .

Архитектура

По принцип имаме настройка за репликация на MariaDB v10.4 с 4 възли с една MaxScale v2.3, която седи върху репликацията, за да разпределя входящи заявки. Само един подчинен е свързан към главен (междинен главен), а другите подчинени устройства се репликират от междинния главен, за да обслужват работни натоварвания за четене, както е показано на следващата диаграма.

Ще превърнем горната топология в това:

По принцип ние ще премахнем междинната главна роля и ще я заменим с binlog сървър, работещ на MaxScale. Междинният главен хост ще бъде преобразуван в стандартен подчинен, точно както другите подчинени хостове. Услугата binlog ще слуша на порт 5306 на хоста MaxScale. Това е портът, към който всички подчинени устройства ще се свързват за репликация по-късно.

Конфигуриране на MaxScale като Binlog сървър

В този пример вече имаме MaxScale, разположен върху нашия клъстер за репликация, който действа като балансьор на натоварването за нашите приложения. Ако нямате MaxScale, можете да използвате ClusterControl за внедряване, просто отидете на Cluster Actions -> Add Load Balancer -> MaxScale и попълнете необходимата информация, както следва:

Преди да започнем, нека експортираме текущата конфигурация на MaxScale в текстов файл за архивиране. MaxScale има флаг, наречен --export-config за тази цел, но той трябва да бъде изпълнен като maxscale потребител. Следователно командата за експортиране е:

$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscale

На главния MariaDB създайте подчинен потребител за репликация, наречен 'maxscale_slave', който да се използва от MaxScale и му присвоете следните привилегии:

$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';

За потребители на ClusterControl отидете на Управление -> Схеми и потребители, за да създадете необходимите привилегии.

Преди да продължим с конфигурацията, важно е да прегледате текущото състояние и топологията на нашите бекенд сървъри:

$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address      │ Port │ Connections │ State                        │ GTID      │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0           │ Master, Running              │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0           │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running               │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running               │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘

Както виждаме, текущият главен код е DB_757 (192.168.0.90). Обърнете внимание на тази информация, тъй като ще настроим binlog сървъра да се репликира от този главен файл.

Отворете конфигурационния файл MaxScale в /etc/maxscale.cnf и добавете следните редове:

[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master

[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0

Малко обяснение - Създаваме два компонента - услуга и слушател. Услугата е мястото, където определяме характеристиката на binlog сървъра и как трябва да работи. Подробности за всяка опция можете да намерите тук. В този пример нашите сървъри за репликация работят с полусинхронизирана репликация, така че трябва да използваме semisync=true, за да се свърже с главната чрез метода на полусинхронна репликация. Слушателят е мястото, където картографираме порта за слушане с услугата binlogrouter в MaxScale.

Рестартирайте MaxScale, за да заредите промените:

$ systemctl restart maxscale

Проверете дали услугата binlog е стартирана чрез maxctrl (вижте колоната State):

$ maxctrl show service replication-service

Уверете се, че MaxScale вече слуша нов порт за услугата binlog:

$ netstat -tulpn | grep maxscale
tcp        0 0 0.0.0.0:3306            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 0.0.0.0:3307            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 0.0.0.0:5306            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 127.0.0.1:8989          0.0.0.0:* LISTEN   4850/maxscale

Вече сме готови да установим връзка за репликация между MaxScale и главния.

Активиране на Binlog сървър

Влезте в главния сървър на MariaDB и извлечете текущия binlog файл и позиция:

MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 |     4204 |              |                  |
+---------------+----------+--------------+------------------+

Използвайте функцията BINLOG_GTID_POS, за да получите стойността на GTID:

MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31                             |
+----------------------------------------+

Обратно към сървъра MaxScale, инсталирайте клиентски пакет MariaDB:

$ yum install -y mysql-client

Свържете се със слушателя на binlog сървъра на порт 5306 като maxscale_slave потребител и установете връзка за репликация към определения главен. Използвайте стойността на GTID, извлечена от главния:

(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                 Slave_IO_State: Binlog Dump
                  Master_Host: 192.168.0.90
                  Master_User: maxscale_slave
                  Master_Port: 3306
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
             Master_Server_Id: 38001
             Master_Info_File: /var/lib/maxscale/binlogs/master.ini
      Slave_SQL_Running_State: Slave running
                  Gtid_IO_Pos: 0-38001-31

Забележка:Горният изход е съкратен, за да показва само важни редове.

Показване на подчинени към сървъра Binlog

Сега на mariadb2 и mariadb3 (крайните подчинени устройства), променете главния, сочещ към сървъра на MaxScale binlog. Тъй като работим с активирана полусинхронизирана репликация, първо трябва да ги изключим:

(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.95
                   Master_User: maxscale_slave
                   Master_Port: 5306
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
              Master_Server_Id: 9999
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-38001-32
       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

Забележка:Горният изход е съкратен, за да показва само важни редове.

Вътре в my.cnf трябва да коментираме следните редове, за да деактивираме полусинхронизирането в бъдеще:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

В този момент междинният главен (mariadb1) все още се репликира от главния (mariadb0), докато други подчинени устройства се репликират от binlog сървъра. Нашата текуща топология може да бъде илюстрирана като диаграмата по-долу:

Последната част е да промените главната точка на междинния главен код (mariadb1 ) след като всички роби, които са се прикрепяли към него, вече не са там. Стъпките са по същество същите с другите подчинени устройства:

(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.95
                   Master_User: maxscale_slave
                   Master_Port: 5306
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
              Master_Server_Id: 9999
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-38001-32

Забележка:Горният изход е съкратен, за да показва само важни редове.

Не забравяйте да деактивирате полусинхронизираната репликация и в my.cnf:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

Можем да проверим, че услугата binlog рутер има повече връзки сега чрез maxctrl CLI:

$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service             │ Router         │ Connections │ Total Connections │ Servers                           │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service          │ readwritesplit │ 1           │ 1                 │ DB_757, DB_758, DB_759, DB_760    │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service          │ readconnroute  │ 1           │ 1                 │ DB_757, DB_758, DB_759, DB_760    │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter   │ 4           │ 51                │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘

Също така, общи команди за администриране на репликация могат да се използват вътре в MaxScale binlog сървъра, например, можем да проверим свързаните подчинени хостове, като използваме тази команда:

(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host         | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003     | 192.168.0.92 | 3306 | 9999      |            |
| 38002     | 192.168.0.91 | 3306 | 9999      |            |
| 38004     | 192.168.0.93 | 3306 | 9999      |            |
+-----------+--------------+------+-----------+------------+

В този момент нашата топология изглежда така, както сме очаквали:

Нашата миграция от междинна главна настройка към настройка на binlog сървър вече е завършена.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Шифроване на база данни:защо и къде трябва да имате криптиране на данни

  2. Как да надстроите MariaDB 5.5 до MariaDB 10.1 на CentOS/RHEL 7 и Debian системи

  3. MariaDB JSON_OBJECTAGG() Обяснено

  4. 4 начина за избор на дублиращи се редове в MariaDB

  5. MariaDB LOCALTIME() Обяснено