MariaDBクラスターの問題をデバッグしようとしています。
Amazon EC2のc4.large
インスタンスでMaria 10.0.19を実行しています。 OSはUbuntu 14.04(Trusty)です。
一緒にクラスター化された3つのマシンがあり、適切に複製されています(一方のマシンでcreate database foo;
を実行し、もう一方のマシンで確認できます)。ただし:ダンプからデータベースを復元しようとした場合3つのマシンすべてが実行されて同期されている間、エラーが発生します。
$ 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
このエラーは、インポートにかかる時間と関係があるようです。クラスター内の3つのノードのうち2つでservice mysql stop
を実行し、残りのノードに対してSQLコマンドを実行すると、正常に動作します。次に、クラスター内の各マシンを1つずつ起動して、SSTを介してデータを複製できるため、これはGalera構成の問題のようです。
これは、大規模なMySQLインポートを実行しているときにのみ発生するわけではありません。小さなトランザクションでの日常的な使用中に発生します。ただし、大量のインポートは、この問題を再現するための最も信頼できる方法です。
インポート中のシステムメモリの使用率はそれほど高くなく、CPUの使用率も高くありません。ネットワークトラフィックは、マシンのリンクの能力をはるかに下回っています。テストでは、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設定(wsrep_cluster_address
のIPアドレス、ドメインなどは意図的に難読化されています):
$ 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)
まず、巨大なトランザクションとLOAD DATA INFILE
on 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システム変数は、トランザクション行をデフォルトで128Kに制限し、トランザクションサイズを1Gbに制限します。必要に応じて、ユーザーはそれらの制限を増やすことができます。将来のバージョンでは、トランザクションの断片化のサポートが追加されます。」
SQLが実際に何を含んでいるかについては不明確ですが、大きなトランザクションがこれらの制限に達する可能性があります。
max_allowed_packetは、mysqldumpを実行したマシンで、設定したものよりも大きくなっている可能性があります。
意味のある情報を提供するようなイベントについては、mysqlエラーログを投稿する必要があります。