我们正在尝试调试 MariaDB 集群的问题。
我们在 Amazon EC2 中的实例上运行 Maria 10.0.19 c4.large；操作系统是 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 导入时发生：在日常使用小型事务时也会发生。不过，大型导入是我们复制此问题最可靠的方法。
导入过程中的系统内存使用率不是特别高，CPU 使用率也不是特别高。网络流量远低于机器链路所能承受的范围，在我们的测试中，除了 SSH 连接之外没有其他流量。
有人可以帮忙了解导致此问题的原因吗？
以下是有关集群中的机器和 MariaDB 配置的更多详细信息：
乌本图：
$ 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 配置（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 <[email protected]> |
| wsrep_provider_version | 3.9(rXXXX) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+---------------------------------------------------+
57 rows in set (0.00 sec)
答案1
首先，巨大的交易和LOAD DATA INFILE在 galera 集群上仍然是一个已知的限制，如果必须的话，建议将这些交易分成 5k-10k trx 或更少的 YMMV。
嘗試增加wsrep-max-ws-size。
innodb_flush_log_at_trx_commit=0在所有节点上设置。
答案2
基于https://mariadb.com/kb/en/mariadb/mariadb-galera-cluster-known-limitations/
“事务大小。虽然 Galera 没有明确限制事务大小，但写入集作为单个内存驻留缓冲区进行处理，因此，极大的事务（例如 LOAD DATA）可能会对节点性能产生不利影响。为了避免这种情况，wsrep_max_ws_rows 和 wsrep_max_ws_size 系统变量默认将事务行限制为 128K，将事务大小限制为 1Gb。如有必要，用户可能希望增加这些限制。未来版本将增加对事务碎片的支持。”
目前尚不清楚您的 SQL 实际包含什么，但是大型交易可能会达到这些限制。
执行 mysqldump 的机器上的 max_allowed_packet 可能比您配置的要大。
您应该发布此类事件的 mysql 错误日志，因为这将提供有意义的信息。