|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Добрый день. Прошу помочь.
Есть 3 сервера mariadb galera cluster multi-master 10.1.14
Балансировка происходит с помощью HAproxy, 2 сервера в нормальном режиме , 3-й сервер поставлен в режим backup. На 3-м сервере соотвецтвенно делается бекап mysql по крону с помощью innobackupex.
Проблема в следуюющем - когда делается fullbackup на сервере 3, два других сервера в кластере начинают плодить запросы которые в основном UPDATE table set, по итогу обращения к кластеру запускает множество запросов и кластер становится не доступен , пока не сделается fullbackup. Когда делаются инкрименты , такой проблемы не наблюдается.
Вот параметр запуска fuulbackup:
$INNOBACKUPEX --user=${MYSQL_USER} --password=${MYSQL_PASSWORD} --no-lock --no-timestamp $backupdir.$DATE >> ${BACKUP_LOG}
Конфигурация кластера :
[mysqld]
bind-address=0.0.0.0
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8
socket=/var/lib/mysql/mysql.sock
datadir = /var/lib/mysql
#innodb_data_home_dir = /var/lib/mysql/
#innodb_undo_directory = /var/lib/mysql
#### TIMEOUT
connect_timeout = 600000
wait_timeout = 28800
max_connections = 400
max_allowed_packet = 512M
max_connect_errors = 10000
net_read_timeout = 600000
net_write_timeout = 600000
#### INNODB
innodb_buffer_pool_size = 12G
innodb_buffer_pool_instances = 6
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 8M
#Innodb_adaptive_hash_index = 0
# Resize ibdata1 to smoll file
innodb_file_per_table = 1
innodb_data_file_path=ibdata1:10M:autoextend
#### OTHER
skip-name-resolve
skip-external-locking
skip-innodb_doublewrite
query_cache_size = 64M
query_cache_limit = 64M
query_cache_type = 1
query_cache_min_res_unit = 2K
thread_handling = pool-of-threads
thread_pool_size = 8
#thread_concurrency = 8
#thread-pool-max-threads = 200
sort_buffer_size = 4M
key_buffer_size = 128M
join_buffer_size = 12M
read_rnd_buffer_size = 8M
read_buffer_size = 8M
table_definition_cache = 2048
table_open_cache = 2048
thread_cache_size = 128
tmp_table_size = 4096M
max_heap_table_size = 4096M
#tmp_table_size = 2048M
#max_heap_table_size = 2048M
log_error = /var/log/mysql/mysql-error.log
[galera]
wsrep_on=ON
binlog_format=ROW
innodb_autoinc_lock_mode=2
transaction-isolation = READ-COMMITTED
default_storage_engine=InnoDB
innodb_log_file_size=512M
innodb_flush_log_at_trx_commit=2
innodb_rollback_on_timeout=1
#innodb_lock_wait_timeout=600
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.10.30,10.10.10.31,10.10.10.32"
#wsrep_cluster_address="gcomm://"
wsrep_cluster_name='galera_cluster'
wsrep_node_address='10.10.10.32'
wsrep_node_name='name1'
wsrep_retry_autocommit = 3
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=repl_user:pass
wsrep_provider_options="gcache.size = 1G"
#wsrep_max_ws_size = 4G
#wsrep_convert_lock_to_trx = 0
[xtrabackup]
target_dir = /data/backups/
[mysqldump]
quick
max_allowed_packet = 16M
Неактивен
А в каком статусе висят запросы? Не успевают сертифицировать транзакции на бэкап-ноде? При sst таких проблем не наблюдается?
Неактивен
Спасибо за ваш ответ.
Запросы висят в статусе Query | 22 | query end .
На бекап ноде висит статус Query | 9 | Writing to net
Но я останавливаю бекап , так как он ложит весь кластер. Для меня очень критично быть онлайн. Может если подождать дольше статус и поменяется на update. Но простой в 30 мин , критичен.
При sst таких проблем не наблюдается? - Что вы имеете в виду ?
P.S Между нодами канал 1гбит/с (локально)
Отредактированно Dimashu (07.07.2016 16:24:48)
Неактивен
Смотрите — галера синхронизируется на этапе COMMIT при сертификации транзакций. Соответственно, если хотя бы одна из живых машинок тормозит в этот момент, сертификации будут идти медленно, и вы получите данный эффект. Query end — это, кажется, как раз это состояние.
Вопрос про SST связан ровно с тем же. SST в Вашей конфигурации делается тоже через xtrabackup, поэтому, если Вы наблюдаете подобный эффект, значит, дело действительно в этом. Если Вы не наблюдаете подобный эффект, значит, точно не оно.
Про «что делать». Так как причина пока непонятна, изучать. Хочется посмотреть на загрузку бэкап-сервера, когда он делает бэкап, а также на SHOW ENGINE INNODB STATUS. Теоретически, xtrabackup открывает только неблокирующую транзакцию, которая не должна мешать сертификации изменений, но я бы поглядел, что там еще крутится.
Неактивен
Во время бекапа ( первые пару минут ) - кластер отвечает но туго. Потом восе ложится
Вот загрузка:
top - 17:19:07 up 3 days, 3:57, 2 users, load average: 1.99, 1.04, 0.68
Tasks: 32 total, 1 running, 31 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.2 sy, 0.0 ni, 77.2 id, 22.5 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 23068672 total, 62016 free, 12406932 used, 10599724 buff/cache
KiB Swap: 23068672 total, 22438600 free, 630072 used. 10536668 avail Mem
Вот вывод SHOW ENGINE INNODB STATUS
| InnoDB | |
=====================================
2016-07-07 17:18:31 7fe48359cb00 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 43 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 130348 srv_active, 0 srv_shutdown, 9391 srv_idle
srv_master_thread log flush and writes: 139739
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 41505
OS WAIT ARRAY INFO: signal count 71436
Mutex spin waits 259929, rounds 1148341, OS waits 23418
RW-shared spins 41389, rounds 624910, OS waits 17669
RW-excl spins 6974, rounds 59117, OS waits 311
Spin rounds per wait: 4.42 mutex, 15.10 RW-shared, 8.48 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 49092552
Purge done for trx's n
< 49092551 undo n < 0 state: running but idle
History list length 1229
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 72255, OS thread handle 0x7fe48359cb00, query id 1427574 localhost root init
SHOW ENGINE INNODB STATUS
---TRANSACTION 49092551, ACTIVE (PREPARED) 0 sec
2 lock struct(s), heap size 360, 1 row lock(s), undo log entries 1
MySQL thread id 2, OS thread handle 0x7fe840800b00, query id 1427573 committing 1437161
Trx #rec lock waits 0 #table lock waits 0
Trx total rec lock wait time 0 SEC
Trx total table lock wait time 0 SEC
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
620740 OS file reads, 3633555 OS file writes, 261553 OS fsyncs
0.28 reads/s, 16384 avg bytes/read, 56.58 writes/s, 0.91 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 4779, seg size 4781, 42240 merges
merged operations:
insert 66480, delete mark 3022653, delete 202921
discarded operations:
insert 0, delete mark 0, delete 0
357.83 hash searches/s, 65.88 non-hash searches/s
---
LOG
---
Log sequence number 116022184524
Log flushed up to 116022182422
Pages flushed up to 116012516325
Last checkpoint at 116012516325
Max checkpoint age 869019772
Checkpoint age target 841862905
Modified age 9668199
Checkpoint age 9668199
0 pending log writes, 0 pending chkp writes
2478496 log i/o's done, 56.58 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 13287555072; in additional pool allocated 0
Total memory allocated by read views 216
Internal hash tables (constant factor + variable factor)
Adaptive hash index 297750480 (203997032 + 93753448)
Page hash 2213656 (buffer pool 0 only)
Dictionary cache 52304312 (51000848 + 1303464)
File system 884464 (812272 + 72192)
Lock system 31876232 (31875512 + 720)
Recovery system 0 (0 + 0)
Dictionary memory allocated 1303464
Buffer pool size 786426
Buffer pool size, bytes 12884803584
Free buffers 129669
Database pages 651035
Old database pages 240425
Modified db pages 4370
Percent of dirty pages(LRU & free pages): 0.560
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 2719, not young 0
0.02 youngs/s, 0.00 non-youngs/s
Pages read 620453, created 30582, written 1154631
0.28 reads/s, 0.58 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 651035, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
----------------------
INDIVIDUAL BUFFER POOL INFO
----------------------
---BUFFER POOL 0
Buffer pool size 131071
Buffer pool size, bytes 2147467264
Free buffers 18564
Database pages 111553
Old database pages 41192
Modified db pages 840
Percent of dirty pages(LRU & free pages): 0.646
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 378, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 105363, created 6190, written 199507
0.02 reads/s, 0.23 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 111553, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 1
Buffer pool size 131071
Buffer pool size, bytes 2147467264
Free buffers 24073
Database pages 106036
Old database pages 39156
Modified db pages 769
Percent of dirty pages(LRU & free pages): 0.591
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 479, not young 0
0.02 youngs/s, 0.00 non-youngs/s
Pages read 101745, created 4291, written 190299
0.02 reads/s, 0.21 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 106036, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 2
Buffer pool size 131071
Buffer pool size, bytes 2147467264
Free buffers 19721
Database pages 110379
Old database pages 40765
Modified db pages 438
Percent of dirty pages(LRU & free pages): 0.337
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 414, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 104968, created 5411, written 179559
0.05 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 110379, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 3
Buffer pool size 131071
Buffer pool size, bytes 2147467264
Free buffers 23954
Database pages 106161
Old database pages 39207
Modified db pages 853
Percent of dirty pages(LRU & free pages): 0.656
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 524, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 101414, created 4747, written 193631
0.09 reads/s, 0.05 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 106161, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 4
Buffer pool size 131071
Buffer pool size, bytes 2147467264
Free buffers 23472
Database pages 106664
Old database pages 39393
Modified db pages 596
Percent of dirty pages(LRU & free pages): 0.458
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 428, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 101607, created 5057, written 180500
0.09 reads/s, 0.02 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 106664, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 5
Buffer pool size 131071
Buffer pool size, bytes 2147467264
Free buffers 19885
Database pages 110242
Old database pages 40712
Modified db pages 874
Percent of dirty pages(LRU & free pages): 0.672
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 496, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 105356, created 4886, written 211135
0.00 reads/s, 0.07 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 110242, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
1 RW transactions active inside InnoDB
0 RO transactions active inside InnoDB
1 out of 1000 descriptors used
Main thread process no. 31271, id 140619519342336, state: sleeping
Number of rows inserted 1772396, updated 1145158, deleted 1140403, read 2396612598
51.56 inserts/s, 9.26 updates/s, 0.05 deletes/s, 9.30 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
На сервере тольк mysql и больше ничего.
Еще момент - все стоит на CentOS 7 - на каких то форумах читал что xtrabackup-v2 на этой версии ОС не поддерживается. Такое может быть ?
Еще раз в часа 3 встречается warning - Warning] WSREP: Failed to report last committed. И к ниму приходят ошибки Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction )
Я так понимаю, если я поставклю SST rsync , то это должно помочь ?
Отредактированно Dimashu (07.07.2016 17:38:40)
Неактивен
Хм, тут вообще не видно этой транзакции, странно. 22.5% wait — 4 ядра и одно из них целиком в диске? Если да, можно попробовать поиграть с ionice. Но вообще — совсем непонятно, почему так себя ведет. Давайте еще посмотрим на
SHOW STATUS LIKE 'wsrep_flow%'. Если там flow control мешает, то можно попробовать его покрутить. Вот тут есть подробности:
https://www.percona.com/blog/2013/05/02 … for-mysql/
Про «не поддерживается» — не знаю, мне казалось, что, если работает, то и хорошо 
Дедлоки бывают, это нормальная ситуация (насколько я понимаю, Вы пишете в оба сервера). Если хотите от них избавиться, то надо писать в один сервер (haproxy это умеет).
Неактивен
Спасибо за совет. Вот вывод flow
MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_flow%';
+------------------------------+---------------+
| Variable_name | Value |
+------------------------------+---------------+
| wsrep_flow_control_paused | 0.022107 |
| wsrep_flow_control_paused_ns | 3267085108864 |
| wsrep_flow_control_recv | 54713 |
| wsrep_flow_control_sent | 14702 |
+------------------------------+---------------+
4 rows in set (0.00 sec)
Но как я понимаю с flow все нормально.
Я так же пытался перевести бекап сервер в состояние Desync на время бекапа , но выполнив команду set global wsrep_desync=ON; Кластер вобоще подвис и пришлось его перезапускать.
Что еще может быть ? Продашен сильно боюсь трогать. На тестовом сервере я такое поведение воспрозвести не могу , так как нагрузки нету.
Так же еще есть 2 небольшие таблички на которой собственно запросы виснут (таблицы в разных БД):
| table_name | engine | total_size_mb | table_rows |
+---------------------------+--------+---------------+------------+
| table | InnoDB | 4775.00 | 26492727 |
table 2 | InnoDB | 10287.00 | 139146605
В бинарном виде они весят раза в 2-3 больше
Ставил ionice -c3 nice -19 - не помагает ((
Отредактированно Dimashu (07.07.2016 19:00:26)
Неактивен
С FC надо смотреть несколько раз, насколько я понимаю. Т.е. что-то типа FLUSH STATUS; SELECT SLEEP(1); SHOW STATUS LIKE 'wsrep_flow%'. Если FC случился в эту секунду, то будет число больше нуля. FC у вас точно посылаются (как минимум 14,5 тысяч раз с бэкапной ноды), интересен, скорее, рейт таких запросов.
С явным desync не работал, но, судя по документации, оно просто отключает FC на ноде, подвисать кластер не должен от этого. Реально все три ноды приходится перезапускать? И вообще ни одна не пускает присоединиться?
Неактивен
Да действительно это значение растет когда я стартую бекап. Вот вывод(дольше ждать не смог отменил бекап):
+------------------------------+---------------+
| Variable_name | Value |
+------------------------------+---------------+
| wsrep_flow_control_paused | 1.000000 |
| wsrep_flow_control_paused_ns | 3949376753020 |
| wsrep_flow_control_recv | 0 |
| wsrep_flow_control_sent | 0 |
+------------------------------+---------------+
Да при выключении desync - произошло все тоже что и при старте Full Backup. Просто все процесы повисли. Чтобы быстрее вернуть , пришлось перезапускать.
Получается что мне нужно установить такие параметры для теста :
set global wsrep_provider_options="gcs.fc_limit=500; gcs.fc_master_slave=YES; gcs.fc_factor=1.0";
Также с документации я не понял , это применение произойдет на одном из кластеров или будет задействовано на всех узлах ?
Неактивен
Насколько я понимаю, ноды не обмениваются никакими настройками никогда, поэтому все изменения будут применены только к конкретной ноде. Попробуйте запустить с большим fc_limit, да. Если блокировка временная, то должно помочь. Если же проблема длительная, то это отодвинет время, когда все сломается (на 500 недосертифицированных транзакций). Но как минимум подтвердим гипотезу.
Неактивен
Не дает установить set global wsrep_provider_options = "gcs.fc_master_slave = yes";
ERROR 1210 (HY000): Incorrect arguments to SET
Остальные команды нормально прошли.
Кстати вот конфиг при запуске, может тут что-то не так. (но я так понимаю все дефолтно)
Passing config to GCS: base_dir = /var/lib/mysql/; base_host = 10.10.10.32; base_port = 4567; cert.log_conflicts = no; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_
keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user
_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 1G; gcs.fc_debug = 0; gcs
.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.segment = 0; gmcas
t.version = 0; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc
Неактивен
paulus написал:
Насколько я понимаю, ноды не обмениваются никакими настройками никогда, поэтому все изменения будут применены только к конкретной ноде. Попробуйте запустить с большим fc_limit, да. Если блокировка временная, то должно помочь. Если же проблема длительная, то это отодвинет время, когда все сломается (на 500 недосертифицированных транзакций). Но как минимум подтвердим гипотезу.
Доброе утро , спасибо Вам огромное за помощь.
Остановился на таком варианте:
ionice -c3 nice -19 , плюс изменил один параметр gcs.fc_limit=500; и запускаю полный бекап когда сервер менее загружен. В такой конфигурации работает.
gcs.fc_master_slave=YES; - этот параметр я так и не нашел как правильно вписать что бы поменять.
Неактивен
Рад, что помогло. А в my.cnf пробовали вписать? Возможно, какие-то параметры динамически не выставляются. В любом случае, если без него работает, то оставляйте так, как есть
Неактивен
В my.cnf не пробовал вписывать. Бекап делается. Пока что так и оставлю )
Но все же что-то не так.
Была ситуация с оптимизацией. Делал оптимизацию и все так же начинало подвисать , ех ((
Отредактированно Dimashu (14.07.2016 12:10:48)
Неактивен
Страниц: 1
