Способността за оформяне на трафика, който отива към базата данни, е една от най-важните. През последните дни не сте имали толкова голям контрол върху него - приложенията изпращаха трафика към базата данни и това е всичко. HAProxy, който беше често използван, също няма опция за фин контрол върху трафика. С въвеждането на прокси сървъри, работещи с SQL, като ProxySQL, за администраторите на бази данни станаха достъпни повече възможности. Нека да разгледаме възможностите за обработка и регулация на връзката в ProxySQL.
Обработка на връзката в ProxySQL
Както може би знаете, начинът, по който ProxySQL работи, е чрез правилата за заявка. Това е списък с правила, срещу които се тества всяка заявка и които управляват точно как ProxySQL ще обработва заявката. Започвайки от самото начало, приложението се свързва с ProxySQL. Той ще се удостовери срещу ProxySQL (ето защо ProxySQL трябва да съхранява всички потребители и хешове на пароли) и след това ProxySQL ще го изпълни през правилата на заявката, за да определи към коя хостгрупа трябва да бъде изпратена заявката.
ProxySQL отваря пул от връзки към задните сървъри. Това не е съпоставяне 1 към 1, по подразбиране се опитва да използва повторно една бекенд връзка за възможно най-много връзки на интерфейса. Това се нарича мултиплексиране на връзката. Подробностите зависят от точния трафик, който трябва да обработва. Всяка отворена транзакция трябва да се обработва в рамките на една и съща връзка. Ако има определен вид локална променлива, тази връзка не може да се използва повторно. Възможността за повторно използване на единична бекенд връзка чрез множество предни връзки намалява значително тежестта върху бекенд базата данни.
След като се осъществи връзката с ProxySQL, както споменахме по-горе, тя ще бъде обработена според правилата на заявката. Тук може да се осъществи оформянето на трафика. Нека да разгледаме опциите
Намаляване на връзката в ProxySQL
Първо, нека просто пуснем всички SELECT. Ние изпълняваме нашето „приложение“, Sysbench, по следния начин:
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --events=200 --time=0 --mysql-host=10.0.0.101 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --report-interval=1 --skip-trx=on --table-size=100000 --db-ps-mode=disable --rate=10 run
sysbench 1.1.0-bbee5d5 (using bundled LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 4
Target transaction rate: 10/sec
Report intermediate results every 1 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 1s ] thds: 4 tps: 5.97 qps: 103.49 (r/w/o: 103.49/0.00/0.00) lat (ms,95%): 244.38 err/s: 0.00 reconn/s: 0.00
[ 1s ] queue length: 0, concurrency: 4
[ 2s ] thds: 4 tps: 13.02 qps: 181.32 (r/w/o: 181.32/0.00/0.00) lat (ms,95%): 580.02 err/s: 0.00 reconn/s: 0.00
[ 2s ] queue length: 5, concurrency: 4
[ 3s ] thds: 4 tps: 14.99 qps: 228.81 (r/w/o: 228.81/0.00/0.00) lat (ms,95%): 669.89 err/s: 0.00 reconn/s: 0.00
[ 3s ] queue length: 1, concurrency: 4
[ 4s ] thds: 4 tps: 16.99 qps: 232.88 (r/w/o: 232.88/0.00/0.00) lat (ms,95%): 350.33 err/s: 0.00 reconn/s: 0.00
[ 4s ] queue length: 0, concurrency: 3
[ 5s ] thds: 4 tps: 8.99 qps: 99.91 (r/w/o: 99.91/0.00/0.00) lat (ms,95%): 369.77 err/s: 0.00 reconn/s: 0.00
[ 5s ] queue length: 0, concurrency: 1
[ 6s ] thds: 4 tps: 3.99 qps: 55.81 (r/w/o: 55.81/0.00/0.00) lat (ms,95%): 147.61 err/s: 0.00 reconn/s: 0.00
[ 6s ] queue length: 0, concurrency: 1
[ 7s ] thds: 4 tps: 11.06 qps: 162.89 (r/w/o: 162.89/0.00/0.00) lat (ms,95%): 173.58 err/s: 0.00 reconn/s: 0.00
[ 7s ] queue length: 0, concurrency: 2
[ 8s ] thds: 4 tps: 7.99 qps: 112.88 (r/w/o: 112.88/0.00/0.00) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00
[ 8s ] queue length: 0, concurrency: 2
[ 9s ] thds: 4 tps: 9.01 qps: 110.09 (r/w/o: 110.09/0.00/0.00) lat (ms,95%): 71.83 err/s: 0.00 reconn/s: 0.00
[ 9s ] queue length: 0, concurrency: 0
[ 10s ] thds: 4 tps: 9.99 qps: 143.87 (r/w/o: 143.87/0.00/0.00) lat (ms,95%): 153.02 err/s: 0.00 reconn/s: 0.00
[ 10s ] queue length: 0, concurrency: 1
[ 11s ] thds: 4 tps: 12.02 qps: 177.28 (r/w/o: 177.28/0.00/0.00) lat (ms,95%): 170.48 err/s: 0.00 reconn/s: 0.00
[ 11s ] queue length: 0, concurrency: 1
[ 12s ] thds: 4 tps: 5.00 qps: 70.95 (r/w/o: 70.95/0.00/0.00) lat (ms,95%): 231.53 err/s: 0.00 reconn/s: 0.00
[ 12s ] queue length: 0, concurrency: 2
[ 13s ] thds: 4 tps: 10.00 qps: 137.01 (r/w/o: 137.01/0.00/0.00) lat (ms,95%): 223.34 err/s: 0.00 reconn/s: 0.00
[ 13s ] queue length: 0, concurrency: 1
[ 14s ] thds: 4 tps: 11.01 qps: 143.14 (r/w/o: 143.14/0.00/0.00) lat (ms,95%): 130.13 err/s: 0.00 reconn/s: 0.00
[ 14s ] queue length: 0, concurrency: 0
[ 15s ] thds: 4 tps: 5.00 qps: 100.99 (r/w/o: 100.99/0.00/0.00) lat (ms,95%): 297.92 err/s: 0.00 reconn/s: 0.00
[ 15s ] queue length: 0, concurrency: 4
[ 16s ] thds: 4 tps: 10.98 qps: 122.82 (r/w/o: 122.82/0.00/0.00) lat (ms,95%): 344.08 err/s: 0.00 reconn/s: 0.00
[ 16s ] queue length: 0, concurrency: 0
[ 17s ] thds: 4 tps: 3.00 qps: 59.01 (r/w/o: 59.01/0.00/0.00) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
[ 17s ] queue length: 0, concurrency: 2
[ 18s ] thds: 4 tps: 13.01 qps: 165.14 (r/w/o: 165.14/0.00/0.00) lat (ms,95%): 173.58 err/s: 0.00 reconn/s: 0.00
[ 18s ] queue length: 0, concurrency: 0
[ 19s ] thds: 4 tps: 6.99 qps: 98.79 (r/w/o: 98.79/0.00/0.00) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 19s ] queue length: 0, concurrency: 1
[ 20s ] thds: 4 tps: 9.98 qps: 164.60 (r/w/o: 164.60/0.00/0.00) lat (ms,95%): 590.56 err/s: 0.00 reconn/s: 0.00
[ 20s ] queue length: 0, concurrency: 3
SQL statistics:
queries performed:
read: 2800
write: 0
other: 0
total: 2800
transactions: 200 (9.64 per sec.)
queries: 2800 (134.89 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
Throughput:
events/s (eps): 9.6352
time elapsed: 20.7573s
total number of events: 200
Latency (ms):
min: 44.36
avg: 202.66
max: 726.59
95th percentile: 590.56
sum: 40531.73
Threads fairness:
events (avg/stddev): 50.0000/0.71
execution time (avg/stddev): 10.1329/0.05Това е трафик само за четене, той трябва да има средно 10 транзакции (140 заявки) в секунда. Тъй като това са само SELECT, можем лесно да променим едно от съществуващите правила за заявка и да блокираме трафика:
Това ще доведе до следната грешка от страната на приложението:
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --events=200 --time=0 --mysql-host=10.0.0.101 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --report-interval=1 --skip-trx=on --table-size=100000 --db-ps-mode=disable --rate=10 run
sysbench 1.1.0-bbee5d5 (using bundled LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 4
Target transaction rate: 10/sec
Report intermediate results every 1 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
FATAL: mysql_drv_query() returned error 1148 (SELECT queries are not allowed!!!) for query 'SELECT c FROM sbtest25 WHERE id=83384'
FATAL: `thread_run' function failed: /usr/local/share/sysbench/oltp_common.lua:426: SQL error, errno = 1148, state = '42000': SELECT queries are not allowed!!!Сега това очевидно е грубо. Можем да бъдем по-учтиви и просто да увеличим забавянето за заявките SELECT.
Това, очевидно, влияе върху производителността на заявките, тъй като се добавят 10 милисекунди към всеки SELECT, който се изпълнява.
SQL statistics:
queries performed:
read: 2800
write: 0
other: 0
total: 2800
transactions: 200 (5.60 per sec.)
queries: 2800 (78.44 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
Throughput:
events/s (eps): 5.6030
time elapsed: 35.6952s
total number of events: 200
Latency (ms):
min: 622.04
avg: 7957.01
max: 18808.60
95th percentile: 15934.78
sum: 1591401.12
Threads fairness:
events (avg/stddev): 50.0000/36.01
execution time (avg/stddev): 397.8503/271.50Настройваме забавяния за всяка заявка SELECT, което не е задължително да има никакъв смисъл, освен да показва, че можете да го направите. Обикновено бихте искали да използвате забавянето при някои нарушителни заявки. Да кажем, че имаме заявка, която е много тежка и добавя значително натоварване на процесора на базата данни. По-лошото е, че е въведен от скорошна промяна на кода и идва от всички хостове на приложения. Разбира се, можете да изчакате разработчиците да върнат промяната или да наложат корекция, но с ProxySQL можете да поемете контрола в свои ръце и просто или да блокирате заявката, или да намалите въздействието й дори доста значително.
Да предположим, че нашата база данни се движи добре, когато алармите започнат да звънят.
Бърз преглед на показателите ни казва, че броят на заявките, изпълнени от ProxySQL намалява, докато използването на процесора се увеличава. Можем да разгледаме най-добрите заявки в ProxySQL, за да видим дали можем да забележим нещо необичайно.
Наистина е необичайно - нова заявка, която не е част от редовен микс от заявки, който наблюдавахме в нашата система. Можем да използваме опцията за създаване на правилото за заявка.
Ще добавим 50 секундно забавяне към заявката, като зададем закъснение на 50000 мс.
Можем да потвърдим, че правилото за заявка се използва и заявките го удрят .
След кратко време можем също да забележим, че натоварването спада и броят на изпълнените заявки отново е в очаквания диапазон. Разбира се, вместо да добавяме забавянето към заявката, можем просто да я блокираме. Това би било още по-лесно за нас, но пълното блокиране на заявката може да окаже значително влияние върху приложението.
Надяваме се, че тази кратка публикация в блога ви дава известна представа за това как ProxySQL може да ви помогне да оформите трафика си и да намалите потискането на производителността, въведено от бягащи заявки.
