Schlagwort: proxysql

Kurztipp: proxysql (1.3.4) mit Galera und proxysql_galera_checker.sh

kero Schreib einen Kommentar

Genauere Informationen zu ProxySQL mit Galera findet man hier. Dort ist auch erklärt wie man das Skript bei proxysql nutzen kann. Das Skript wird vorzugsweise vom ProxySQL Scheduler aufgerufen. Man kann es aber natürlich auch einfach mal auf der Commandline testen.
Meiner Meinung nach wird sich das eh im Laufe der nächsten Versionen nochmal grundlegend ändern. Das ist alles relativ umfangreich,  daher nur ein paar Hinweise.

Das Skript  liegt unter
/usr/share/proxysql/tools/proxysql_galera_checker.sh

Ein Aufruf sieht in etwa so aus

$ ./proxysql_galera_checker.sh 1 0 2 0 /var/lib/proxysql/galerachecker.log

 

Das erste Parameter gibt die Hostgroup für der Writer an, das zweite die Reader Hostgroup. Die 2  ist die Anzahl der genutzten Writers und die letzte 0 gibt an ob Writer auch als Reader agieren sollen wenn sie in der gleichen Hostgroup wie die Reader sind und als letztes Argument der Pfad zum Log.

Schaut man nun in das Logfile findet man folgendes:

Fr 3. Mär 13:22:10 CET 2017 ###### proxysql_galera_checker.sh SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 Hostgroup writers 1
Fr 3. Mär 13:22:10 CET 2017 Hostgroup readers 0
Fr 3. Mär 13:22:10 CET 2017 Number of writers 2
Fr 3. Mär 13:22:10 CET 2017 Writers are readers 0
Fr 3. Mär 13:22:10 CET 2017 log file /var/lib/proxysql/proxysql_galera_checker.log
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE WRITER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera3:3306 is already ONLINE: 1 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera4:3306 is already ONLINE: 2 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE READER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera1:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera1:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera2:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera2:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera3:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera4:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 ###### SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 --> Number of writers that are 'ONLINE': 2 : hostgroup: 1
Fr 3. Mär 13:22:10 CET 2017 --> Number of readers that are 'ONLINE': 2 : hostgroup: 0
Fr 3. Mär 13:22:10 CET 2017 ###### Loading mysql_servers config into runtime ######

Wir haben also 4 Nodes,  Galera3  und 4 aus Hostgroup 1 werden zu Writern und Galera1 und 2 aus Hostgroup 0 werden zu Readern. Galera3 und 4 sind auch in Hostgroup 1, dort werden sie aber Aufgrund des „writes should not be readers“ Arguments deaktiviert.

Wichtig dabei ist:

„…ProxySQL uses a chain of query rules to figure out the routing. If none of the rules apply to a query, query will be routed to the default hostgroup for the user, which created the connection.“

https://severalnines.com/blog/how-proxysql-adds-failover-and-query-control-your-mysql-replication-setup

Das ganze Konstrukt ergibt quasi nur Sinn wenn man auch mit query rules arbeitet.  So kann man aber „bequem“ read/write Anfragen skalieren und die volle Kapazität des Clusters nutzen.

So eine richtige Meinung zu ProxySQL habe ich noch nicht. Diese Sache mit den Hostgruppen finde ich jedenfalls ziemlich gut.  Ob  nun MaxScale oder ProxySQL die bessere Lösung ist kann ich nicht ohne weiteres sagen, sondern das hängt sicherlich von der jeweiligen Anforderung ab.  Für genauere Aussagen müsste man sich das mal in einer Produktivumgebung anschauen und sich ausführlicher mit den beiden Tools beschäftigen. Die Lizenz von ProxySQL ist natürlich deutlich sympathischer.

Link:
http://www.proxysql.com/compare

 

Kurztipp: ProxySQL…missed 3 heartbeats

kero Schreib einen Kommentar

Tauchen bei ProxySQL in der Logdatei immer wieder Einträge in der Art

...MySQL_Monitor.cpp:1126:monitor_ping(): [ERROR] Server db7:3306 missed 3 heartbeats, shunning it and killing all the connections

auf, liegt es eventuell daran, dass kein mysql-monitor_username mit dem mysql-monitor_password auf den Nodes eingerichtet ist.  Als Folge davon unterbricht ProxySQL die Verbindung zu den Nodes. Einfach mal bei ProxySQL schauen was dort eingetragen ist. Default ist monitor/monitor (jedenfalls in der 1.3.3er).

mysql> SELECT * FROM global_variables WHERE variable_name IN ('mysql-monitor_username','mysql-monitor_password','mysql-monitor_connect_interval','mysql-monitor_ping_interval','mysql-monitor_history');

+--------------------------------+------------------+
| variable_name                  | variable_value   |
+--------------------------------+------------------+
| mysql-monitor_connect_interval | 60000            |
| mysql-monitor_history          | 600000           |
| mysql-monitor_password         | monitor          |
| mysql-monitor_ping_interval    | 10000            |
| mysql-monitor_username         | monitor          |
+--------------------------------+------------------+
5 rows in set (0.01 sec)

Ändern kann man das Passwort einfach mit

mysql> UPDATE global_variables SET variable_value="GEHIRNSABOTAGE" WHERE variable_name="mysql-monitor_password";
Query OK, 1 row affected (0.00 sec)

mysql> LOAD MYSQL VARIABLES TO RUNTIME;
Query OK, 0 rows affected (0.00 sec)

mysql> SAVE MYSQL VARIABLES TO DISK;
Query OK, 46 rows affected (0.00 sec)

und fertig. Der Monitoraccount muss natürlich auch auf den Nodes eingetragen werden. Dann sollten auch Tests mit Sysbench & Co funktionieren.

Über

http://proxysql.blogspot.de/2015/09/proxysql-tutorial-setup-in-mysql.html

bin ich drauf gekommen.