Какво е новото в MariaDB MaxScale 2.4

MaxScale 2.4 беше пуснат на 21 декември 2019 г., а ClusterControl 1.7.6 поддържа наблюдението и управлението до тази версия. Въпреки това, за внедряване, ClusterControl поддържа само до версия 2.3. Човек трябва ръчно да надстрои екземпляра ръчно и за щастие стъпките за надграждане са много ясни. Просто изтеглете най-новата версия от страницата за изтегляне на MariaDB MaxScale и изпълнете командата за инсталиране на пакета.

Следните команди показват как да надстроите от съществуващ MaxScale 2.3 до MaxScale 2.4 на кутия CentOS 7:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

В тази публикация в блога ще подчертаем някои от забележителните подобрения и нови функции на тази версия и как изглежда в действие. За пълен списък с промените в MariaDB MaxScale 2.4, вижте неговия регистър на промените.

История на командите в интерактивен режим

Това е основно малко подобрение със значително въздействие върху администрирането на MaxScale и ефективността на задачите за наблюдение. Интерактивният режим за MaxCtrl вече има своя история на командите. Историята на командите лесно ви позволява да повторите изпълнената команда чрез натискане на клавиша със стрелка нагоре или надолу. Въпреки това, функционалността Ctrl+R (припомнете си последната команда, съответстваща на знаците, които предоставяте) все още не е налице.

В предишните версии човек трябва да използва стандартния режим на обвивка, за да се увери, че командите са уловени от .bash_history файл.

Наблюдение на GTID за galeramon

Това е добро подобрение за тези, които работят на Galera Cluster с географско резервиране чрез асинхронна репликация, известна още като репликация от клъстер към клъстер или MariaDB Galera Cluster репликация през MariaDB репликация.

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

За MaxScale 2.4 сега изглежда така (обърнете внимание на Galera1 на ред):

Вече е по-лесно да видите състоянието на репликация за всички възли от MaxScale, без необходимостта от многократна проверка на отделни възли.

SmartRouter

Това е една от новите основни функции в MaxScale 2.4, където MaxScale вече е достатъчно интелигентен, за да научи кой бекенд сървър на MariaDB е най-добрият за обработка на заявката. SmartRouter следи производителността или времето за изпълнение на заявките към клъстерите. Измерванията се съхраняват с каноничната на заявка като ключ. Каноничното на заявката е SQL с всички дефинирани от потребителя константи, заменени с въпросителни, например:

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ?

Това е много полезна функция, ако използвате MariaDB на многосайтово географско репликация или комбинация от машини за съхранение на MariaDB в една верига за репликация, например, специален подчинен за обработка на работни натоварвания на транзакции (OLTP ) с InnoDB механизъм за съхранение и друг специален подчинен за обработка на аналитични работни натоварвания (OLAP) с машина за съхранение на Columnstore.

Да предположим, че имаме два сайта - Сидни и Сингапур, както е илюстрирано на следната диаграма:

Основният сайт се намира в Сингапур и има MariaDB главен и подчинен , докато друго подчинено устройство само за четене се намира в Сидни. Приложението се свързва с модела MaxScale, намиращ се в съответната държава със следните настройки на порта:

Разделяне на четене-запис:3306
Кръгла система:3307
Интелигентен рутер:3308

Нашата услуга SmarRouter и дефиниции на слушател са:

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******

[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

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

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

От горното можем да разберем, че MaxScale на Сидни е препратил горната заявка към роба на нашия Сингапур, което не е най-добрата опция за маршрутизиране само по себе си.

Когато SmartRouter слуша на порт 3308, ще видим, че заявката се насочва към най-близкия подчинен в Сидни:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

И ако същата заявка се изпълни в нашия сайт в Сингапур, тя ще бъде насочена към подчинения на MariaDB, намиращ се в Сингапур:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Има една уловка. Когато SmartRouter види заявка за четене, чиято канонична не е била виждана преди, той ще изпрати заявката до всички клъстери. Първият отговор от клъстер ще определи този клъстер като най-добрия за този каноничен. Също така, когато се получи първият отговор, останалите заявки се анулират. Отговорът се изпраща на клиента, след като всички клъстери са отговорили на заявката или на анулирането.

Това означава, че за да следите каноничната заявка (нормализирана заявка) и да измерите нейната производителност, вероятно ще видите, че първата заявка се проваля при първото й изпълнение, например:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

От общия регистрационен файл в MariaDB Sydney можем да кажем, че първата заявка (ID 74) е изпълнена успешно (свързване, заявка и изход), въпреки грешката „Загубена връзка“ от MaxScale:

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Докато идентичната последваща заявка беше правилно обработена и върната с правилния отговор:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

Като погледнем отново общия регистрационен файл в MariaDB Sydney (ID 75), се случиха същите събития за обработка, точно като първата заявка:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

От това наблюдение можем да заключим, че понякога MaxScale трябва да провали първата заявка, за да измери производителността и да стане по-интелигентна за следващите идентични заявки. Вашето приложение трябва да може да се справи правилно с тази „първа грешка“, преди да се върне към клиента или да опита отново транзакцията.

UNIX сокет за сървър

Има няколко начина за свързване към работещ MySQL или MariaDB сървър. Можете да използвате стандартния мрежов TCP/IP с IP адрес и порт на хоста (отдалечена връзка), наречени тръби/споделена памет на Windows или Unix файлове на сокет на Unix-базирани системи. UNIX сокетният файл е специален вид файл, който улеснява комуникацията между различни процеси, които в този случай са MySQL клиента и сървъра. Файлът на сокета е комуникация, базирана на файл, и не можете да получите достъп до сокета от друга машина. Той осигурява по-бърза връзка от TCP/IP (без мрежови разходи) и по-сигурен подход за свързване, тъй като може да се използва само при свързване към услуга или процес на същия компютър.

Ако предположим, че сървърът MaxScale също е инсталиран на самия сървър MariaDB, вместо това можем да използваме сокетния UNIX файл. Под секцията Сървър премахнете или коментирайте реда „адрес“ и добавете параметъра на сокета с местоположението на файла на сокета:

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Преди да приложим горните промени, трябва да създадем потребител на MaxScale axscale от localhost. На главния сървър:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

След рестарт, MaxScale ще покаже пътя на UNIX сокета вместо действителния адрес, а списъкът със сървъра ще бъде показан така:

Както можете да видите, информацията за състоянието и GTID се извлича правилно чрез връзка със сокет. Имайте предвид, че този DB_2 все още слуша порт 3306 за отдалечените връзки. Това просто показва, че MaxScale използва сокет за свързване към този сървър за наблюдение.

Използването на сокет винаги е по-добро поради факта, че позволява само локални връзки и е по-сигурно. Можете също така да затворите сървъра на MariaDB от мрежата (напр. --skip-networking) и да оставите MaxScale да обработва „външните“ връзки и да ги препрати към сървъра на MariaDB чрез UNIX файл на сокет.

Източване на сървъра

В MaxScale 2.4 задните сървъри могат да бъдат източени, което означава, че съществуващите връзки могат да продължат да се използват, но няма да се създават нови връзки към сървъра. С функцията за източване можем да извършим изящна дейност по поддръжка, без да засягаме потребителското изживяване от страна на приложението. Имайте предвид, че източването на сървър може да отнеме повече време в зависимост от изпълняваните заявки, които трябва да бъдат изящно затворени.

За да източите сървър, използвайте следната команда:

Последният ефект може да бъде едно от следните състояния:

Източване – Сървърът се източва.
Източен - Сървърът е изтощен. Сървърът се изтощаваше и сега броят на връзките към сървъра падна до 0.
Поддръжка – Сървърът е в процес на поддръжка.

След като сървърът е изтощен, състоянието на сървъра на MariaDB от гледна точка на MaxScale е "Поддръжка":

Когато сървърът е в режим на поддръжка, няма да се създават връзки към него и съществуващите връзки ще бъдат затворени.

Заключение

MaxScale 2.4 носи много подобрения и промени в сравнение с предишната версия и е най-добрият прокси за база данни за работа със сървърите на MariaDB и всички негови компоненти.