ProxySQL е един от най-добрите прокси сървъри за MySQL. Той въведе много опции за администраторите на бази данни. Това направи възможно оформянето на трафика на базата данни чрез забавяне, кеширане или пренаписване на заявки в движение. Може да се използва и за създаване на среда, в която преминаването на отказ няма да засяга приложенията и ще бъде прозрачно за тях. Вече разгледахме най-важните функции на ProxySQL в предишни публикации в блога:
- Как да използвам ClusterControl и ProxySQL за кеширане на заявки
- Как да изградим SQL защитна стена с ClusterControl и ProxySQL
- Как да разположите ProxySQL клъстер
- Как лесно да разположите среда за репликация на MySQL с ProxySQL за висока наличност
Имаме дори урок, обхващащ ProxySQL, показващ как може да се използва в настройките на MySQL и MariaDB.
Съвсем наскоро беше пуснат ProxySQL 2.0.3, който е версия на корекция за серията 2.0. Поправят се грешки и изглежда, че линията 2.0 започва да получава сцеплението, което заслужава. В тази публикация в блога бихме искали да обсъдим основните промени, въведени в ProxySQL 2.0.
Каузални четения с помощта на GTID
Всеки, който трябваше да се справя със забавяне на репликацията и се бори със сценарии за четене след запис, които са засегнати от забавянето на репликацията, определено ще бъдат много доволни от тази функция. Досега в среди за репликация на MySQL единственият начин да се гарантира причинно-следственото четене беше да се чете от главния (и няма значение дали използвате асинхронна или полусинхронна репликация). Друга възможност беше да се използва Galera, която имаше опция за налагане на причинно-следствени четения, тъй като винаги (първо беше wsrep-causal-reads, а сега е wsrep-sync-wait). Съвсем наскоро (в 8.0.14) MySQL Group репликацията получи подобна функция. Редовната репликация обаче сама по себе си не може да се справи с този проблем. За щастие, ProxySQL е тук и ни дава възможност да дефинираме на базата на правило за всяка заявка с това какво чете хостгрупата, кои съвпадения с това правило за заявка трябва да са последователни. Реализацията идва с ProxySQL binlog reader и може да работи с ROW binlog формат за MySQL 5.7 и по-нови. Поддържа се само Oracle MySQL поради липса на необходимата функционалност в MariaDB. Тази функция и нейните технически подробности са обяснени в официалния блог на ProxySQL.
SSL за Frontend Connections
ProxySQL винаги имаше поддръжка за бекенд SSL връзка, но липсваше SSL криптиране за връзките, идващи от клиенти. Това не беше толкова голяма работа, като се има предвид, че препоръчителният модел за внедряване беше да се разположи ProxySQL на възли на приложението и да се използва защитен Unix сокет за свързване от приложението към прокси сървъра. Това все още е препоръка, особено ако използвате ProxySQL за кеширане на заявки (Unix сокетите са по-бързи от TCP връзката, дори локалните и с кеша е добре да избягвате въвеждането на ненужно забавяне). Хубавото е, че с ProxySQL 2.0 вече има избор, тъй като въведе SSL поддръжка за входящи връзки. Можете лесно да го активирате, като зададете mysql-have_ssl на „true“. Активирането на SSL не идва с неприемливо въздействие върху производителността. Обратно, според резултатите от официалния блог на ProxySQL, спадът в производителността е много нисък.
Естествена поддръжка за Galera Cluster
Galera Cluster се поддържа от ProxySQL почти от самото начало, но досега това беше направено чрез външен скрипт, който (обикновено) се извиква от вътрешния планировчик на ProxySQL. От скрипта зависи да гарантира, че конфигурацията на ProxySQL е правилна, записващият (или записващите) е правилно открит и конфигуриран в хост групата на писателите. Скриптът успя да открие различните състояния, които възелът на Galera може да има (първичен, неосновен, синхронизиран, донор/десинхрон, присъединяване, присъединен) и съответно да маркира възела като наличен или не. Основният проблем е, че оригиналният скрипт никога не е бил предназначен за нещо различно от доказателство за концепция, написана на Bash. И все пак, тъй като беше разпространен заедно с ProxySQL, той започна да се подобрява, модифициран от външни сътрудници. Други (като Percona) се заеха със създаването на свои собствени скриптове, в комплект с техния софтуер. Някои поправки бяха въведени в скрипта от хранилището на ProxySQL, някои бяха въведени във версията на скрипта на Percona. Това доведе до объркване и въпреки че всички често използвани скриптове обработваха 95% от случаите на употреба, нито един от популярните не покриваше всички различни ситуации и променливи, които Galera cluster може да използва. За щастие ProxySQL 2.0 идва с вградена поддръжка за Galera Cluster. Това кара ProxySQL да поддържа вътрешно MySQL репликация, MySQL Group Replication и сега Galera Cluster. Начинът на това как се прави е много подобен. Бихме искали да покрием конфигурацията на тази функция, тъй като може да не е ясна на пръв поглед.
Както при MySQL репликацията и MySQL Group Replication, в ProxySQL е създадена таблица:
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Има много настройки за конфигуриране и ще ги разгледаме една по една. На първо място, има четири хостгрупи:
- Writer_hostgroup – ще съдържа всички записващи (с read_only=0) до настройката „max_writers“. По подразбиране е само един писател
- Backup_writer_hostgroup – съдържа оставащи записващи (read_only=0), които остават след добавяне на „max_writers“ към writer_hostgroup
- Reader_hostgroup – съдържа четци (read_only=1), може да съдържа и резервни записващи средства, съгласно настройката „writer_is_also_reader“
- Offline_hostgroup – съдържа възли, които се считат за неизползваеми (или офлайн, или в състояние, което ги прави невъзможни за обработка на трафика)
След това имаме останалите настройки:
- Активен – дали записът в mysql_galera_hostgroups е активен или не
- Max_writers – най-много възли могат да бъдат поставени в writer_hostgroup
- Writer_is_also_reader – ако е зададено на 0, записващите (read_only=0) няма да бъдат поставени в reader_hostgroup. Ако е зададено на 1, записващите (read_only=0) ще бъдат поставени в reader_hostgroup. Ако е зададено на 2, възлите от backup_writer_hostgroup ще бъдат поставени в reader_hostgroup. Този е малко сложен, затова ще представим пример по-късно в тази публикация в блога
- Max_transactions_behind – въз основа на wsrep_local_recv_queue, максималната опашка, която е приемлива. Ако опашката на възела надвишава max_transactions_behind, даденият възел ще бъде маркиран като ИЗБЯГАН и няма да бъде достъпен за трафика
Основната изненада може да бъде боравенето с читателите, което е различно от това как работи скриптът, включен в ProxySQL. На първо място, това, което трябва да имате предвид, е фактът, че ProxySQL използва read_only=1, за да реши дали node е четец или не. Това е често срещано при настройките за репликация, не толкова често в Galera. Следователно най-вероятно ще искате да използвате настройката „writer_is_also_reader“, за да конфигурирате как читателите трябва да се добавят към reader_hostgroup. Нека разгледаме три възела на Galera, всички те имат read_only=0. Също така имаме max_writers=1, тъй като искаме да насочим всички записи към един възел. Конфигурирахме mysql_galera_hostgroups, както следва:
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Нека да преминем през всички опции:
writer_is_also_reader=0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Този резултат е различен от този, който бихте видели в скриптовете - там ще имате останалите възли, маркирани като читатели. Тук, като се има предвид, че не искаме писателите да бъдат читатели и като се има предвид, че няма възел с read_only=1, няма да бъдат конфигурирани читатели. Един записващ (съгласно max_writers), останалите възли в backup_writer_hostgroup.
writer_is_also_reader=1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Тук искаме нашите писатели да действат като читатели, следователно всички те (активни и резервни) ще бъдат поставени в reader_hostgroup.
writer_is_also_reader=2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)Това е настройка за тези, които не искат техният активен писател да се справя с четенето. В този случай само възли от backup_writer_hostgroup ще се използват за четене. Моля, имайте предвид също, че броят на читателите ще се промени, ако зададете max_writers на друга стойност. Ако го зададем на 3, няма да има резервни записващи устройства (всички възли ще се озоват в хост групата за записване), така че отново няма да има възли в хост групата за четене.
Разбира се, вие ще искате да конфигурирате правилата за заявка в съответствие с конфигурацията на хост групата. Тук няма да преминаваме през този процес, можете да проверите как може да се направи в блога на ProxySQL. Ако искате да тествате как работи в Docker среда, имаме блог, който обхваща как да стартирате клъстер Galera и ProxySQL 2.0 на Docker.
Други промени
Това, което описахме по-горе, са най-забележителните подобрения в ProxySQL 2.0. Има много други, според регистъра на промените. Струва си да се спомене подобренията около кеша на заявките (например добавяне на PROXYSQL FLUSH QUERY CACHE) и промяна, която позволява на ProxySQL да разчита на super_read_only за определяне на главния и подчинения в настройката за репликация.
Надяваме се, че този кратък преглед на промените в ProxySQL 2.0 ще ви помогне да определите коя версия на ProxySQL трябва да използвате. Моля, имайте предвид, че клон 1.4, дори и да няма нови функции, той все още се поддържа.
