HAProxy en ProxySQL zijn beide erg populaire load balancers in de MySQL-wereld, maar er is een significant verschil tussen beide proxy's. We zullen hier niet in details treden, u kunt meer lezen over HAProxy in HAProxy Tutorial en ProxySQL in ProxySQL Tutorial. Het belangrijkste verschil is dat ProxySQL een SQL-bewuste proxy is, het verkeer ontleedt en het MySQL-protocol begrijpt en als zodanig kan worden gebruikt voor geavanceerde verkeersvorming - u kunt query's blokkeren, ze herschrijven, ze naar bepaalde hosts sturen, cache hen en nog veel meer. HAProxy, aan de andere kant, is een zeer eenvoudige maar efficiënte laag 4-proxy en het enige dat het doet is pakketten naar de backend sturen. ProxySQL kan worden gebruikt om een lees-schrijfsplitsing uit te voeren - het begrijpt de SQL en het kan worden geconfigureerd om te detecteren of een query SELECT is of niet en deze dienovereenkomstig te routeren:SELECT's naar alle knooppunten, andere query's alleen voor master. Deze functie is niet beschikbaar in HAProxy, dat twee afzonderlijke poorten en twee afzonderlijke backends voor master en slaves moet gebruiken - de lees-schrijfsplitsing moet worden uitgevoerd aan de applicatiezijde.
Waarom migreren naar ProxySQL?
Op basis van de verschillen die we hierboven hebben uitgelegd, zouden we zeggen dat de belangrijkste reden waarom u van HAProxy naar ProxySQL zou willen overstappen, het ontbreken van de lees-schrijfsplitsing in HAProxy is. Als u een cluster van MySQL-databases gebruikt, en het maakt niet echt uit of het asynchrone replicatie of Galera Cluster is, wilt u waarschijnlijk lezen en schrijven kunnen splitsen. Voor MySQL-replicatie is dit natuurlijk de enige manier om uw databasecluster te gebruiken, aangezien schrijfbewerkingen altijd naar de master moeten worden verzonden. Dus als u de lees-schrijfsplitsing niet kunt uitvoeren, kunt u alleen query's naar de master sturen. Voor Galera is read-write split geen must-have maar wel een good-to-have. Natuurlijk kun je alle Galera-knooppunten configureren als één backend in HAProxy en verkeer naar alle knooppunten sturen in round-robin-mode, maar dit kan ertoe leiden dat schrijfacties van meerdere knooppunten met elkaar in conflict komen, wat leidt tot impasses en prestatieverlies. We hebben ook problemen en bugs gezien binnen het Galera-cluster, waarvoor de tijdelijke oplossing was om alle schrijfbewerkingen naar een enkel knooppunt te leiden, totdat ze waren opgelost. De beste werkwijze is dus om alle schrijfbewerkingen naar één Galera-knooppunt te sturen, omdat dit leidt tot stabieler gedrag en betere prestaties.
Een andere zeer goede reden voor migratie naar ProxySQL is de behoefte aan betere controle over het verkeer. Met HAProxy kun je niets doen - het stuurt het verkeer alleen naar zijn backends. Met ProxySQL kunt u uw verkeer vormgeven met behulp van queryregels (overeenkomstig verkeer met behulp van reguliere expressies, gebruiker, schema, bronhost en nog veel meer). U kunt OLAP SELECT's omleiden naar analyseslave (dit geldt voor zowel replicatie als Galera). U kunt uw master ontladen door enkele van de SELECT's ervan om te leiden. U kunt een SQL-firewall implementeren. U kunt een vertraging toevoegen aan sommige van de query's, u kunt query's beëindigen als ze meer dan een vooraf gedefinieerde tijd in beslag nemen. U kunt query's herschrijven om optimalisatietips toe te voegen. Dat is allemaal niet mogelijk met HAProxy.
Hoe migreren van HAProxy naar ProxySQL?
Laten we eerst eens kijken naar de volgende topologie...
ClusterControl MySQL-topologie 
MySQL-replicatiecluster in ClusterControl We hebben hier een replicatiecluster bestaande uit een master en twee slaves. We hebben twee HAProxy-knooppunten geïmplementeerd, die elk twee backends gebruiken - op poort 3307 voor master (schrijven) en 3308 voor alle knooppunten (lezen). Keepalive wordt gebruikt om een virtueel IP-adres aan te bieden voor die twee HAProxy-instanties - mocht een van de twee niet werken, dan wordt een andere gebruikt. Onze applicatie maakt rechtstreeks verbinding met de VIP, via een van de HAProxy-instanties. Laten we aannemen dat onze applicatie (we zullen Sysbench gebruiken) de lees-schrijfsplitsing niet kan uitvoeren, daarom moeten we verbinding maken met de "schrijver" -backend. Als gevolg hiervan ligt het grootste deel van de belasting op onze master (10.0.0.101).
Wat zijn de stappen om naar ProxySQL te migreren? Laten we er even over nadenken. Eerst moeten we ProxySQL implementeren en configureren. We zullen servers aan ProxySQL moeten toevoegen, de vereiste monitoringgebruikers moeten creëren en de juiste queryregels moeten creëren. Ten slotte zullen we Keepalived bovenop ProxySQL moeten implementeren, een ander virtueel IP-adres moeten maken en vervolgens moeten zorgen voor een zo naadloos mogelijke overstap voor onze applicatie van HAProxy naar ProxySQL.
Laten we eens kijken hoe we dat kunnen bereiken...
ProxySQL installeren
Men kan ProxySQL op vele manieren installeren. U kunt de repository gebruiken, hetzij vanuit ProxySQL zelf (https://repo.proxysql.com) of als u Percona XtraDB Cluster gebruikt, kunt u ook ProxySQL installeren vanuit de Percona-repository, hoewel het mogelijk enige aanvullende configuratie vereist omdat het afhankelijk is van CLI admin-tools gemaakt voor PXC. Aangezien we het over replicatie hebben, kan het gebruik ervan de zaken alleen maar complexer maken. Ten slotte kunt u ook ProxySQL-binaire bestanden installeren nadat u ze van ProxySQL GitHub hebt gedownload. Momenteel zijn er twee stabiele versies, 1.4.x en 2.0.x. Er zijn verschillen tussen ProxySQL 1.4 en ProxySQL 2.0 qua features, voor deze blog houden we het bij de 1.4.x branch, omdat deze beter getest is en de featureset voor ons voldoende is.
We zullen ProxySQL-repository gebruiken en we zullen ProxySQL implementeren op twee extra knooppunten:10.0.0.103 en 10.0.0.104.
Eerst zullen we ProxySQL installeren met behulp van de officiële repository. We zullen er ook voor zorgen dat de MySQL-client is geïnstalleerd (we zullen deze gebruiken om ProxySQL te configureren). Houd er rekening mee dat het proces dat we doorlopen niet van productiekwaliteit is. Voor productie wilt u op zijn minst de standaardreferenties voor de administratieve gebruiker wijzigen. U zult ook de configuratie willen bekijken en ervoor zorgen dat deze in overeenstemming is met uw verwachtingen en vereisten.
apt-get install -y lsb-release
wget -O - 'https://repo.proxysql.com/ProxySQL/repo_pub_key' | apt-key add -
echo deb https://repo.proxysql.com/ProxySQL/proxysql-1.4.x/$(lsb_release -sc)/ ./ | tee /etc/apt/sources.list.d/proxysql.list
apt-get -y update
apt-get -y install proxysql
service proxysql startNu ProxySQL is gestart, zullen we de CLI gebruiken om ProxySQL te configureren.
mysql -uadmin -padmin -P6032 -h127.0.0.1Eerst zullen we backend-servers en replicatie-hostgroepen definiëren:
mysql> INSERT INTO mysql_servers (hostgroup_id, hostname) VALUES (10, '10.0.0.101'), (20, '10.0.0.102'), (20, '10.0.0.103');
Query OK, 3 rows affected (0.91 sec)mysql> INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (10, 20);
Query OK, 1 row affected (0.00 sec)We hebben drie servers, we hebben ook gedefinieerd dat ProxySQL hostgroep 10 moet gebruiken voor master (node met read_only=0) en hostgroep 20 voor slaves (read_only=1).
Als volgende stap moeten we een monitoringgebruiker toevoegen aan de MySQL-knooppunten zodat ProxySQL ze kan bewaken. We gaan voor standaardinstellingen, idealiter wijzigt u de inloggegevens in ProxySQL.
mysql> SHOW VARIABLES LIKE 'mysql-monitor_username';
+------------------------+---------+
| Variable_name | Value |
+------------------------+---------+
| mysql-monitor_username | monitor |
+------------------------+---------+
1 row in set (0.00 sec)mysql> SHOW VARIABLES LIKE 'mysql-monitor_password';
+------------------------+---------+
| Variable_name | Value |
+------------------------+---------+
| mysql-monitor_password | monitor |
+------------------------+---------+
1 row in set (0.00 sec)We moeten dus een gebruiker 'monitor' maken met het wachtwoord 'monitor'. Om dat te doen, moeten we de volgende toekenning uitvoeren op de master MySQL-server:
mysql> create user [email protected]'%' identified by 'monitor';
Query OK, 0 rows affected (0.56 sec)Terug naar ProxySQL - we moeten gebruikers configureren die onze applicatie zal gebruiken om toegang te krijgen tot MySQL en queryregels, die bedoeld zijn om ons een lees-schrijfsplitsing te geven.
mysql> INSERT INTO mysql_users (username, password, default_hostgroup) VALUES ('sbtest', 'sbtest', 10);
Query OK, 1 row affected (0.34 sec)mysql> INSERT INTO mysql_query_rules (rule_id,active,match_digest,destination_hostgroup,apply) VALUES (100, 1, '^SELECT.*FOR UPDATE$',10,1), (200,1,'^SELECT',20,1), (300,1,'.*',10,1);
Query OK, 3 rows affected (0.01 sec)Houd er rekening mee dat we het wachtwoord in de platte tekst hebben gebruikt en dat we zullen vertrouwen op ProxySQL om het te hashen. Om veiligheidsredenen moet u hier expliciet de MySQL-wachtwoordhash doorgeven.
Ten slotte moeten we alle wijzigingen toepassen.
mysql> LOAD MYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.02 sec)mysql> LOAD MYSQL USERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> LOAD MYSQL QUERY RULES TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE MYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.07 sec)mysql> SAVE MYSQL QUERY RULES TO DISK;
Query OK, 0 rows affected (0.02 sec)We willen ook de gehashte wachtwoorden laden vanuit runtime:wachtwoorden in platte tekst worden gehasht wanneer ze in de runtime-configuratie worden geladen, om het gehasht op schijf te houden, moeten we het vanuit runtime laden en vervolgens op schijf opslaan:
mysql> SAVE MYSQL USERS FROM RUNTIME;
Query OK, 0 rows affected (0.00 sec)mysql> SAVE MYSQL USERS TO DISK;
Query OK, 0 rows affected (0.02 sec)Dit is het als het gaat om ProxySQL. Voordat u verdere stappen onderneemt, moet u controleren of u verbinding kunt maken met proxy's van uw applicatieservers.
[email protected]:~# mysql -h 10.0.0.103 -usbtest -psbtest -P6033 -e "SELECT * FROM sbtest.sbtest4 LIMIT 1\G"
mysql: [Warning] Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
id: 1
k: 50147
c: 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441
pad: 22195207048-70116052123-74140395089-76317954521-98694025897In ons geval ziet alles er goed uit. Nu is het tijd om Keepalive te installeren.
Bewaarde installatie
Installatie is vrij eenvoudig (tenminste op Ubuntu 16.04, die we gebruikten):
apt install keepalivedVervolgens moet u configuratiebestanden voor beide servers maken:
Master keepalive node:
vrrp_script chk_haproxy {
script "killall -0 haproxy" # verify the pid existance
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance VI_HAPROXY {
interface eth1 # interface to monitor
state MASTER
virtual_router_id 52 # Assign one ID for this route
priority 101
unicast_src_ip 10.0.0.103
unicast_peer {
10.0.0.104
}
virtual_ipaddress {
10.0.0.112 # the virtual IP
}
track_script {
chk_haproxy
}
# notify /usr/local/bin/notify_keepalived.sh
}Backup keepalive node:
vrrp_script chk_haproxy {
script "killall -0 haproxy" # verify the pid existance
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance VI_HAPROXY {
interface eth1 # interface to monitor
state MASTER
virtual_router_id 52 # Assign one ID for this route
priority 100
unicast_src_ip 10.0.0.103
unicast_peer {
10.0.0.104
}
virtual_ipaddress {
10.0.0.112 # the virtual IP
}
track_script {
chk_haproxy
}
# notify /usr/local/bin/notify_keepalived.shDit is het, je kunt keepalive starten op beide nodes:
service keepalived startU zou in de logboeken informatie moeten zien dat een van de nodes de MASTER-status is binnengegaan en dat VIP op die node is grootgebracht.
May 7 09:52:11 vagrant systemd[1]: Starting Keepalive Daemon (LVS and VRRP)...
May 7 09:52:11 vagrant Keepalived[26686]: Starting Keepalived v1.2.24 (08/06,2018)
May 7 09:52:11 vagrant Keepalived[26686]: Opening file '/etc/keepalived/keepalived.conf'.
May 7 09:52:11 vagrant Keepalived[26696]: Starting Healthcheck child process, pid=26697
May 7 09:52:11 vagrant Keepalived[26696]: Starting VRRP child process, pid=26698
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Initializing ipvs
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Registering Kernel netlink reflector
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Registering Kernel netlink command channel
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Registering gratuitous ARP shared channel
May 7 09:52:11 vagrant systemd[1]: Started Keepalive Daemon (LVS and VRRP).
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Unable to load ipset library
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Unable to initialise ipsets
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Opening file '/etc/keepalived/keepalived.conf'.
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Using LinkWatch kernel netlink reflector...
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Registering Kernel netlink reflector
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Registering Kernel netlink command channel
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Opening file '/etc/keepalived/keepalived.conf'.
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Using LinkWatch kernel netlink reflector...
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: pid 26701 exited with status 256
May 7 09:52:12 vagrant Keepalived_vrrp[26698]: VRRP_Instance(VI_HAPROXY) Transition to MASTER STATE
May 7 09:52:13 vagrant Keepalived_vrrp[26698]: pid 26763 exited with status 256
May 7 09:52:13 vagrant Keepalived_vrrp[26698]: VRRP_Instance(VI_HAPROXY) Entering MASTER STATE
May 7 09:52:15 vagrant Keepalived_vrrp[26698]: pid 26806 exited with status 256[email protected]:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:ee:87:c4 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:feee:87c4/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:fc:ac:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.103/24 brd 10.0.0.255 scope global eth1
valid_lft forever preferred_lft forever
inet 10.0.0.112/32 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fefc:ac21/64 scope link
valid_lft forever preferred_lft foreverZoals je kunt zien, is er op node 10.0.0.103 een VIP (10.0.0.112) aan de orde gesteld. We kunnen nu afsluiten met het verplaatsen van het verkeer van de oude setup naar de nieuwe.
Verkeer overschakelen naar een ProxySQL-configuratie
Er zijn veel methoden om dit te doen, het hangt meestal af van uw specifieke omgeving. Als u DNS gebruikt om een domein te onderhouden dat naar uw HAProxy VIP verwijst, kunt u daar een wijziging aanbrengen en geleidelijk zullen alle verbindingen opnieuw naar de nieuwe VIP verwijzen. U kunt ook een wijziging aanbrengen in uw toepassing, vooral als de verbindingsdetails hardcoded zijn - zodra u de wijziging heeft geïmplementeerd, zullen knooppunten verbinding maken met de nieuwe installatie. Hoe je het ook doet, het zou geweldig zijn om de nieuwe setup te testen voordat je een globale overstap maakt. Je hebt het zeker getest in je staging-omgeving, maar het is geen slecht idee om een handvol app-servers te kiezen en ze om te leiden naar de nieuwe proxy, om te controleren hoe ze er qua prestaties uitzien. Hieronder ziet u een eenvoudig voorbeeld waarin iptables worden gebruikt, wat handig kan zijn bij het testen.
Leid op de ProxySQL-hosts verkeer van host 10.0.0.11 en poort 3307 om naar host 10.0.0.112 en poort 6033:
iptables -t nat -A OUTPUT -p tcp -d 10.0.0.111 --dport 3307 -j DNAT --to-destination 10.0.0.112:6033Afhankelijk van uw toepassing moet u mogelijk de webserver of andere services opnieuw opstarten (als uw app een constante pool van verbindingen met de database maakt) of gewoon wachten tot er nieuwe verbindingen worden geopend tegen ProxySQL. U kunt controleren of ProxySQL het verkeer ontvangt:
mysql> show processlist;
+-----------+--------+--------+-----------+---------+---------+-----------------------------------------------------------------------------+
| SessionID | user | db | hostgroup | command | time_ms | info |
+-----------+--------+--------+-----------+---------+---------+-----------------------------------------------------------------------------+
| 12 | sbtest | sbtest | 20 | Sleep | 0 | |
| 13 | sbtest | sbtest | 10 | Query | 0 | DELETE FROM sbtest23 WHERE id=49957 |
| 14 | sbtest | sbtest | 10 | Query | 59 | DELETE FROM sbtest11 WHERE id=50185 |
| 15 | sbtest | sbtest | 20 | Query | 59 | SELECT c FROM sbtest8 WHERE id=46054 |
| 16 | sbtest | sbtest | 20 | Query | 0 | SELECT DISTINCT c FROM sbtest27 WHERE id BETWEEN 50115 AND 50214 ORDER BY c |
| 17 | sbtest | sbtest | 10 | Query | 0 | DELETE FROM sbtest32 WHERE id=50084 |
| 18 | sbtest | sbtest | 10 | Query | 26 | DELETE FROM sbtest28 WHERE id=34611 |
| 19 | sbtest | sbtest | 10 | Query | 16 | DELETE FROM sbtest4 WHERE id=50151 |
+-----------+--------+--------+-----------+---------+---------+-----------------------------------------------------------------------------+Dat was het, we hebben het verkeer van HAProxy naar ProxySQL-configuratie verplaatst. Er waren wat stappen voor nodig, maar het is zeker te doen met een zeer kleine onderbreking van de service.
Hoe migreren van HAProxy naar ProxySQL met ClusterControl?
In de vorige sectie hebben we uitgelegd hoe u ProxySQL-setup handmatig implementeert en er vervolgens naar migreert. In deze sectie willen we uitleggen hoe u hetzelfde doel kunt bereiken met ClusterControl. De initiële setup is precies hetzelfde, daarom moeten we doorgaan met de implementatie van ProxySQL.
ProxySQL implementeren met ClusterControl
Implementatie van ProxySQL in ClusterControl is slechts een kwestie van een handvol klikken.
ProxySQL implementeren in ClusterControl We moesten het IP-adres of de hostnaam van een knooppunt kiezen, de inloggegevens doorgeven voor de CLI-beheerder en de MySQL-monitoringgebruiker. We hebben besloten om bestaande MySQL te gebruiken en we hebben toegangsgegevens doorgegeven voor de 'sbtest'@'%'-gebruiker die we in de applicatie gebruiken. We hebben gekozen welke knooppunten we in de load balancer willen gebruiken, we hebben ook de maximale replicatievertraging verhoogd (als die drempel wordt overschreden, zal ProxySQL het verkeer niet naar die slaaf sturen) van standaard 10 seconden naar 100 omdat we al last hebben van de replicatie vertraging. Na korte tijd zullen ProxySQL-knooppunten aan het cluster worden toegevoegd.
Keepalived implementeren voor ProxySQL met ClusterControl
Wanneer ProxySQL-knooppunten zijn toegevoegd, is het tijd om Keepalive te implementeren.
Keepalived met ProxySQL in ClusterControl Het enige dat we hoefden te doen, is kiezen op welke ProxySQL-knooppunten we Keepalived willen inzetten, virtueel IP en interface waaraan VIP zal worden gebonden. Wanneer de implementatie is voltooid, schakelen we het verkeer over naar de nieuwe configuratie met behulp van een van de methoden die worden genoemd in het gedeelte 'Verkeer naar ProxySQL-configuratie' hierboven.
ProxySQL-verkeer bewaken in ClusterControl We kunnen controleren of het verkeer is overgeschakeld naar ProxySQL door naar de belastingsgrafiek te kijken - zoals u kunt zien, is de belasting veel meer verdeeld over de knooppunten in het cluster. Je kunt het ook zien in de onderstaande grafiek, die de verdeling van de zoekopdrachten over het cluster laat zien.
ProxySQL-dashboard in ClusterControl Ten slotte laat het ProxySQL-dashboard ook zien dat het verkeer wordt verdeeld over alle knooppunten in het cluster:
ProxySQL-dashboard in ClusterControl We hopen dat u zult profiteren van deze blogpost, zoals u kunt zien, met ClusterControl, het implementeren van de nieuwe architectuur duurt slechts een moment en vereist slechts een handvol klikken om dingen aan de gang te krijgen. Laat ons weten wat uw ervaring met dergelijke migraties is.