MariaDB Galera Cluster легко не синхронизируется
Мы пытаемся отладить проблему с кластером MariaDB.
Мы работаем с Марией 10.0.19 на c4.large экземпляры в Amazon EC2; ОС Ubuntu 14.04 (Trusty).
Есть три машины, сгруппированные вместе, нормально копируемые (мы можем запустить create database foo; на одной машине и посмотреть ее на другой и тд).Но: когда мы пытаемся восстановить базу данных из дампа, когда все три машины работают и синхронизируются, возникает ошибка:
$ du -sh *.sql
2.7G sqldump.sql
$ cat sqldump.sql | sudo mysql
ERROR 1047 (08S01) at line 4361: WSREP has not yet prepared node for application use
Кажется, эта ошибка связана с тем, сколько времени занимает импорт. Если мы бежим service mysql stop на двух из трех узлов в кластере и запустите команду SQL для оставшегося узла, она работает нормально. Затем мы можем запустить каждую из машин в кластере одну за другой для репликации данных через SST, поэтому кажется, что это проблема конфигурации Galera.
Это происходит не только при выполнении большого импорта MySQL: это происходит во время обычного использования с небольшими транзакциями. Большой импорт - наш самый надежный способ воспроизвести эту проблему.
Использование системной памяти при импорте не особенно высокое, равно как и загрузка ЦП. Сетевой трафик намного ниже того, на что способен канал машины, и в нашем тесте нет другого трафика, кроме нашего SSH-соединения.
Может кто-нибудь, пожалуйста, помогите понять, что может быть причиной этой проблемы?
Вот еще несколько подробностей о машинах в кластере и конфигурации MariaDB:
Ubuntu:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty
Ядро:
$ uname -a
Linux servername.domain 3.13.0-53-generic #89-Ubuntu SMP Wed May 20 10:34:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
MySQL config (IP-адреса, домен и т. Д. В wsrep_cluster_address намеренно запутано)
$ find /etc/mysql/ -name "*.cnf" -exec cat {} \; | egrep -v "^#" | grep v "^$"
[mysqld]
server-id = 965424531
bind-address = *
max_connections = 500
max_connect_errors = 1000000
innodb_buffer_pool_size = 2635M
log_bin = /var/lib/mysql/mysql/mysql-bin
expire_logs_days = 7
sync_binlog = 1
binlog_format = MIXED
log-slave-updates = 1
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
[mysqld]
innodb_use_native_aio = 0
innodb_flush_method = O_DSYNC
[client]
[mysqld]
[mysqld_safe]
syslog
[mariadb]
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 127.0.0.1
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error.log
expire_logs_days = 10
max_binlog_size = 100M
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
[mysqld]
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_debug=ON
wsrep_cluster_name="clustername"
wsrep_cluster_address="gcomm://10.0.X.X,10.0.X.X"
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:sstpassword
wsrep_node_address="10.0.1.10"
wsrep_node_name="servername.domain"
binlog_format=ROW
wsrep_on=ON
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
query_cache_size=0
innodb_log_file_size = 256M
Состояние кластера:
$ sudo mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 288
Server version: 10.0.19-MariaDB-1~trusty-wsrep-log mariadb.org binary distribution, wsrep_25.10.r4144
Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show status like '%wsrep%';
+------------------------------+---------------------------------------------------+
| Variable_name | Value |
+------------------------------+---------------------------------------------------+
| wsrep_local_state_uuid | e856afdc-18af-11e5-a3a6-efccde439ba4 |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 45764 |
| wsrep_replicated | 2031 |
| wsrep_replicated_bytes | 1527494811 |
| wsrep_repl_keys | 9973524 |
| wsrep_repl_keys_bytes | 79839767 |
| wsrep_repl_data_bytes | 1447525060 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 1478 |
| wsrep_received_bytes | 13040 |
| wsrep_local_commits | 1750 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 2 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.001140 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 7 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.043302 |
| wsrep_local_cached_downto | 45564 |
| wsrep_flow_control_paused_ns | 3956186469 |
| wsrep_flow_control_paused | 0.005006 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 41 |
| wsrep_cert_deps_distance | 4.487445 |
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.000000 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 11438 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.000000 |
| wsrep_incoming_addresses | ,, |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0.00059098/0.000958534/0.00469729/0.000375612/732 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | 8bcfefe4-25f7-11e5-be32-062acc002ed5 |
| wsrep_cluster_conf_id | 88 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | e856afdc-18af-11e5-a3a6-efccde439ba4 |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 2 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 3.9(rXXXX) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+---------------------------------------------------+
57 rows in set (0.00 sec)
2 ответа
Во-первых, огромные транзакции и LOAD DATA INFILEНа кластере Galera все еще известное ограничение, если вам нужно, рекомендуется разделить эти транзакции на 5k-10k trx или менее YMMV.
Попробуйте увеличить wsrep-max-ws-size,
Задавать innodb_flush_log_at_trx_commit=0 на всех узлах.
На основе https://mariadb.com/kb/en/mariadb/mariadb-galera-cluster-known-limitations/
"Размер транзакции. Хотя Galera явно не ограничивает размер транзакции, набор записей обрабатывается как отдельный резидентный буфер, и в результате очень большие транзакции (например, LOAD DATA) могут отрицательно повлиять на производительность узла. Во избежание этого wsrep_max_ws_rows и системные переменные wsrep_max_ws_size ограничивают строки транзакции до 128 КБ, а размер транзакции по умолчанию составляет 1 ГБ. При необходимости пользователи могут захотеть увеличить эти ограничения. В будущих версиях будет добавлена поддержка фрагментации транзакций ".
Непонятно, что на самом деле содержит ваш SQL, однако большие транзакции могут выйти за эти пределы.
max_allowed_packet может быть больше на машине, которая выполнила mysqldump, чем то, что вы настроили.
Вы должны опубликовать свой журнал ошибок mysql для таких событий, поскольку он предоставит значимую информацию.