ランダムにデータベースが完全にロックされ、クエリがハングし、「接続が多すぎます」になるまでクエリが蓄積されます。
以下は私のmysqlログファイルです。エラーシステムコールに関連するものは何も見つかりませんでした。
Aug 28 14:06:36 db1a mysqld: 2015-08-28 14:06:36 11786 [Note] WSREP: Created page /var/data/mysql/gcache.page.000008 of size 134217728 bytes
Aug 28 14:07:06 db1a mysqld: 2015-08-28 14:07:06 11786 [Note] WSREP: Deleted page /var/data/mysql/gcache.page.000008
Aug 28 16:39:38 db1a mysqld: 2015-08-28 16:39:38 11786 [Note] WSREP: Created page /var/data/mysql/gcache.page.000009 of size 134217728 bytes
Aug 28 16:39:48 db1a mysqld: 2015-08-28 16:39:48 11786 [Note] WSREP: Deleted page /var/data/mysql/gcache.page.000009
Aug 28 19:42:07 db1a mysqld: 2015-08-28 19:42:07 11786 [Note] WSREP: Created page /var/data/mysql/gcache.page.000010 of size 134217728 bytes
Aug 28 19:42:08 db1a mysqld: 2015-08-28 19:42:08 11786 [Note] WSREP: Created page /var/data/mysql/gcache.page.000011 of size 134217728 bytes
Aug 28 19:42:10 db1a mysqld: 2015-08-28 19:42:10 11786 [Warning] WSREP: Failed to report last committed 758795619, -4 (Interrupted system call)
Aug 28 19:42:45 db1a mysqld: 2015-08-28 19:42:45 11786 [Warning] WSREP: Failed to report last committed 758795879, -4 (Interrupted system call)
Aug 28 19:43:07 db1a mysqld: 2015-08-28 19:43:07 11786 [Warning] WSREP: Failed to report last committed 758796011, -4 (Interrupted system call)
Aug 28 19:43:11 db1a mysqld: 2015-08-28 19:43:11 11786 [Warning] WSREP: Failed to report last committed 758796012, -4 (Interrupted system call)
Aug 28 19:43:49 db1a mysqld: 2015-08-28 19:43:49 11786 [Warning] Too many connections
Aug 28 19:43:49 db1a mysqld: 2015-08-28 19:43:49 11786 [Warning] Too many connections
Aug 28 19:43:50 db1a mysqld: 2015-08-28 19:43:50 11786 [Warning] Too many connections
Aug 28 19:43:51 db1a mysqld: 2015-08-28 19:43:51 11786 [Warning] Too many connections
MySQLは私のアプリケーションでこのエラーをスローし始めます:
'SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction
バージョン:5.6.24-72.2-56-log Percona XtraDB Cluster(GPL)、リリースrel72.2、リビジョン43abf03、WSREPバージョン25.11、wsrep_25.11
my.cnf
# -- SERVER ---------------------------------------------- #
[mysqld_safe]
pid-file = /var/data/run/mysqld.pid
socket = /var/data/run/mysqld.sock
Nice = 0
flush_caches = 1
numa_interleave = 1
syslog
[mysqld]
user = mysql
pid-file = /var/data/run/mysqld.pid
socket = /var/data/run/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/data/mysql
tmpdir = /mnt/tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
default_time_zone = America/New_York
character-set-server = utf8
collation-server = utf8_general_ci
transaction-isolation = READ-COMMITTED
# -- Cluster Settings -------------------------- #
# Path to Galera library
wsrep_provider = /usr/lib/libgalera_smm.so
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
# It should be empty during bootstrap
wsrep_cluster_address=gcomm://10.0.200.8,10.0.210.7
#wsrep_cluster_address=gcomm://
# In order for Galera to work correctly binlog format should be ROW
binlog_format = ROW
# MyISAM storage engine has only experimental support
default_storage_engine = InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode = 2
# We don't trust auto_increment control from galera when nodes are removed and added
# to the cluster, each node has a different offset.
wsrep_auto_increment_control = OFF
auto_increment_increment = 3
auto_increment_offset = 1
# Node #1 address
wsrep_node_address = 10.0.200.7
# Cluster and node name
wsrep_cluster_name = db1
wsrep_node_name = db1a
# SST method
wsrep_sst_method = xtrabackup-v2
wsrep_sst_auth = "db1:XXXXXXXXXXXX"
wsrep_sst_receive_address = 10.0.200.7
wsrep_sst_donor = db1b,db1c
wsrep_slave_threads = 4
# ---------------------------------------------- #
#
# * Timeouts
#
connect_timeout = 5
lock_wait_timeout = 3600
interactive_timeout = 1800
wait_timeout = 3600
#
# * Buffer
#
key_buffer_size = 32M
sort_buffer_size = 4M
read_rnd_buffer_size = 4M
join_buffer_size = 4M
max_allowed_packet = 64M
thread_stack = 512K
thread_cache_size = 12
table_open_cache = 4096
open_files_limit = 65536
max_heap_table_size = 1G
tmp_table_size = 1G
myisam-recover = BACKUP
max_connections = 500
#
# * Query Cache Configuration
#
# Cache size needs to be set to 0 before start with XtrabDB cluster
# It can ben changed during runtime
# http://www.percona.com/doc/percona-xtradb-cluster/5.6/limitation.html
query_cache_type = 1
query_cache_limit = 10M
query_cache_size = 0
#
# * Logging and Replication
#
# It has to be logged to FILE to work with XtraDB Cluster
# http://www.percona.com/doc/percona-xtradb-cluster/5.6/limitation.html
log_output = FILE
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1
#log_error = /var/log/mysql/error.log
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 10
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
server-id = 1
log_bin = /var/data/log/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 512M
log_bin_trust_function_creators = 1
log-slave-updates
innodb_buffer_pool_size = 48G
innodb_buffer_pool_instances = 10
innodb_log_file_size = 1G
innodb_log_buffer_size = 256M
innodb_thread_concurrency = 0
innodb_file_format = Barracuda
innodb_flush_method = O_DIRECT
innodb_lock_wait_timeout = 60
innodb_read_io_threads = 64
innodb_write_io_threads = 32
innodb_ft_enable_stopword = 0
innodb_ft_min_token_size = 2
innodb_flush_log_at_trx_commit = 0
innodb_open_files = 4096
# NUMA improvement
innodb_buffer_pool_populate = 1
innodb_file_per_table
#
# * Security
#
ssl-ca = /etc/ssl/certs/CA.crt
ssl-cert = /etc/mysql/keys/db1a.crt
ssl-key = /etc/mysql/keys/db1a.key
この問題はあなただけではないと思います。マルチマスターレプリケーションを停止し、代わりにRAIDとXtraBackupを強化しました。5.5または5.6の問題はありませんでした。
ただし、wsrepとクラスタリングを使用すると、これらの問題が発生します。まだ解決策があるかどうかは不明ですが、最善の策は、このスレッドをフォローすることです。
これがお役に立てば幸いです。その記事が、問題の診断に使用できる「Perconaエンジニアの口から」のコマンドが最も役立つと思います。
Perconaエンジニアのヒントを要約するには、もちろんエラーログを確認してください:
show status like 'wsrep%';
また、記事に記載されているいくつかのツール。 DBソフトウェアを実行するすべてのサーバーのAnsibleプレイブックにある1つのことは、最大オープンファイル制限(ulimit -n)などを増やすことです。
効果があるかどうかはわかりませんが、PerconaのPeterは、権限を付与するときにmax_connectionsを明示的に設定することをお勧めします。私はそれを試していませんが、問題がどこにあるか、または実際にそれがクラスターに関連している場合、これを試し、診断するのにも役立ちます。
mysql> GRANT USAGE ON *.* TO 'batchjob1'@'localhost'
-> WITH MAX_USER_CONNECTIONS 10;
最近、Percona XtraDBクラスター5.6.21-70でいくつかの広範なベンチマークを実行し、クラスターに対してトランザクション(挿入、更新、削除)を実行すると、32スレッド後にパフォーマンスが低下することに気付きました。次に、1つのノードに対してのみテストを実行し、32スレッドでの低下を解消しました。アプリをクラスターに向けるのではなく、専用ノードに向けます。フェイルオーバーにはLinux LVSを使用しており、かなりうまくいきます。
これは、ガレラではトラフィックが高すぎるときに「正常」です。すべての書き込みは他のすべてのノードでレプリケートする必要があるため、クラスター上の書き込みトラフィックの量はN-1で乗算されます。Nはクラスター内のノードの数です。書き込みがノード間で均等に分散されている場合、負荷が高すぎると、クラスターの競合が頻繁に発生し、最終的にはトランザクションのバックログが積み重なってしまいます。
これは単にCAP定理の数学的確実性の産物です: https://en.wikipedia.org/wiki/CAP_theorem
アプリケーションからDBへの書き込み量を減らすためにできることがあれば、これを行う必要があります。個々のノード(およびノード間のネットワーク)の書き込みスループットを向上させる方法がある場合は、これも行う必要があります。たとえば、ストレージにSSDキャッシュをインストールしたため、トランザクション時間が大幅に短縮されました。これによりしばらくの間問題が緩和されましたが、トラフィック量が増加したため、負荷がかかっている状態でクラスターの障害を完全に防ぐにはまだ不十分でした。
現在、HAProxyを使用して、すべての読み取りと書き込みを単一のノードに送信しています。そのノードに障害が発生した場合、HAProxyは別のノードを選択し、すべてのトラフィックをそのノードに転送します。信頼性に関しては、これはマスタースレーブ構成よりも優れていますが、それにはパフォーマンスのトレードオフがあります。パフォーマンス上の利点の1つは、バックアップ、レポート、1回限りのクエリなどの読み取り専用トラフィックを非マスターノードに転送できたことです。これにより、アプリケーションの一般的なパフォーマンスに対するそのようなタスクの影響が大幅に減少しました。