アーカイブ「2018年08月」

以前の投稿で、spider engineを使った際、

flush tables;

を使わないと、バックエンドに正常にクエリーが流れないことを記載した。

 

調査した結果、

spider_use_handler=1

を設定することで、正しくバックエンドにクエリーが流れることが確認できた。

上記パラメータは以下の公式にある。

https://mariadb.com/kb/en/library/spider-server-system-variables/#spider_use_handler

しかし、このパラメータはなんなのか。。

なぜ、handler socketが出てくるのか。。

 

というわけで、spider関連の設定を備忘録として載せておく。

spider_bka_mode=1
spider_conn_recycle_mode=1
spider_connect_retry_count=2
spider_connect_retry_interval=1000
spider_connect_timeout=10
spider_crd_sync=0
spider_direct_dup_insert=1
spider_local_lock_table=0
spider_log_result_errors=2
spider_max_connections=0
spider_net_read_timeout=10
spider_net_write_timeout=10
spider_remote_access_charset=utf8mb4
spider_remote_autocommit=0
spider_remote_sql_log_off=0
spider_reset_sql_alloc=0
spider_sts_sync=0
spider_support_xa=0
spider_sync_autocommit=0
spider_sync_trx_isolation=0
spider_use_handler=1

 

別途クエリー挙動をまとめようと思います。

 

以上

投稿日時:2018年08月14日 16:57   カテゴリー:mariadb   [コメントがあればどうぞ]

spider engineを検証していたら、謎の挙動に出会った。

簡単に言うと、whereでpartition条件句を含めたクエリーを発行したのち、

whereがないクエリーを発行すると、partition条件句の向き先となったノードに発行先が固定されるというもの。

試したバージョンは、

MariaDB:10.3.8

Spider:3.3.13

である。

 

原因がよくわかっていないのだが、

flush tables;

コマンドを発行すると治る。。

セッションを終了しても治らない。。

 

高速化のため、spider側で何かしらキャッシュしていることが原因なのではないかと考えているが、

どうも気持ち悪く、バグなのか仕様なのかも現在はっきりしていない。

原因が判明したら、また記載しようと思います。

また、MariaDB10.1にバンドルされていた3.2.37とは動きが異なる部分が多かったので、

検証完了次第、詳細な動き(パターン)を合わせて記載出来たらと思います。

 

以上

投稿日時:2018年08月06日 18:21   カテゴリー:mariadb   [コメントがあればどうぞ]

MariaDBの以下のクラスター方式で、パフォーマンス比較をしてみた。

比較動機としては、galeraは本当に遅いか?ということを確認するためのものです。

  1. standalone(比較用)
  2. semi sync
  3. galera

 

環境はvagrantの仮想マシンで、以下構成とバージョン。

CPU:1core、MEMORY:512MB

OS:CentOS7.5

MariaDB:10.3.8

 

sysbenchの実行スクリプトは以下の通りで、${thread}の部分は1と2で実施。

$ sudo sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--table-size=100000 \
--mysql-host=192.168.35.11 \
--mysql-user=admin \
--mysql-password=adminpassword \
--time=60 \
--db-ps-mode=disable \
--threads=${thread} run

 

テストにおけるインスタンス配置は以下の通り。

1.standalone

----------
sysbench
ip:192.168.35.10
----------
 |
 |
 |
----------
db01
ip:192.168.35.11
----------

 

2.semi sync

----------
sysbench
ip:192.168.35.10
----------
 |
 |
 |
-----------------------
db01
ip:192.168.35.11
-----------------------
  |               |
  |(replication)  |(replication)
  |               |
 ----------       ----------
 db02             db03
 ip:192.168.35.12 ip:192.168.35.13
 ----------       ----------

 

3.galera

----------
sysbench
ip:192.168.35.10
----------
 |
 |
 |
-----------------------
db01
ip:192.168.35.11
-----------------------
  |                |
  |(write set)     |(write set)
  |                |
 ----------       ----------
 db02             db03
 ip:192.168.35.12 ip:192.168.35.13
 ----------       ----------

 

ざっくりパラメータは以下の通りで、条件によって、変更していく。

# --------------------------------------------------
# base
# --------------------------------------------------
server_id=${server_id}
user=mysql
bind_address=0.0.0.0
pid_file=/var/run/mysql/mysqld.pid
port=3306
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
sql_mode=TRADITIONAL
default_storage_engine=InnoDB
transaction_isolation=READ-COMMITTED
character_set_server=utf8mb4
collation_server=utf8mb4_general_ci
thread_pool_max_threads=100
thread_handling=pool-of-threads
extra_port=3307
extra_max_connections=10

# --------------------------------------------------
# network
# --------------------------------------------------
max_connections=50
max_connect_errors=999999999
connect_timeout=10
max_allowed_packet=16M
back_log=1024

# --------------------------------------------------
# logging
# --------------------------------------------------
log_output=FILE
log_error=/var/log/mysql/error.log
slow_query_log=1
long_query_time=1
log_queries_not_using_indexes=0
slow_query_log_file=/var/log/mysql/slow.log
general_log=0
general_log_file=/var/log/mysql/general.log

# --------------------------------------------------
# cache, memory
# --------------------------------------------------
query_cache_size=0
max_heap_table_size=32M
tmp_table_size=32M

# --------------------------------------------------
# session
# --------------------------------------------------
sort_buffer_size=4M
read_rnd_buffer_size=2M
read_buffer_size=512K
join_buffer_size=512K

# --------------------------------------------------
# innodb
# --------------------------------------------------
innodb_buffer_pool_load_at_startup=1
innodb_buffer_pool_dump_at_shutdown=1
innodb_buffer_pool_dump_pct=25
innodb_fast_shutdown=0
innodb_flush_log_at_trx_commit=1    // set globalで適宜変更
innodb_autoinc_lock_mode=2
innodb_doublewrite=ON
innodb_file_per_table=1
innodb_log_buffer_size=16M
innodb_buffer_pool_size=256M
innodb_flush_neighbors=0
innodb_read_ahead_threshold=0
innodb_log_file_size=64M
innodb_log_files_in_group=2
innodb_buffer_pool_instances=8
innodb_lru_scan_depth=1024
innodb_read_io_threads=1
innodb_write_io_threads=1
innodb_io_capacity=100
innodb_io_capacity_max=1000
innodb_open_files=1024
innodb_purge_threads=1
innodb_sync_array_size=2
innodb_flush_method=O_DIRECT

# --------------------------------------------------
# replication
# --------------------------------------------------
report_host=${ip_addr}
read_only=0
binlog_format=row
log_bin=mariadb-bin
max_binlog_size=128M
sync_binlog=1        // set globalで適宜変更
expire_logs_days=3
log_slave_updates=1
relay_log_recovery=1
slave_max_allowed_packet=1G
slave_net_timeout=3600
slave_parallel_threads=1
gtid_strict_mode=1

# --------------------------------------------------
# semisync
# --------------------------------------------------
{if (semi syncのときのみ)}
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1500
rpl_semi_sync_slave_enabled=1
rpl_semi_sync_master_wait_point=AFTER_SYNC
{endif}

# --------------------------------------------------
# galera
# --------------------------------------------------
{if (galeraのときのみ)}
wsrep_on=1
wsrep_cluster_name=db-cluster
wsrep_cluster_address=gcomm://192.168.35.11,192.168.35.12,192.168.35.13
wsrep_node_address=${ip_addr}
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_sst_method=rsync
wsrep_slave_threads=1
wsrep_provider_options="gcache.recover=yes; gcache.size=1G; gcs.fc_factor=1.0; gcs.fc_limit=256; gcs.fc_master_slave=yes;"
{endif}

という前提でテストをした結果が以下の通り。

結果を見てみると、

semi sync3とgalera2は遜色がないことがわかる。

semi syncよりgaleraは遅いと思っていたが、そうとも言えないのかもしれない。

とはいえ、あくまでsysbenchの結果であり、トランザクションの量や、スレッドの量によって、

結果は変わるものなので、あくまで一つの指標として、「galeraは早くないけど、遅いとも言い切れない」ってことがわかった気がします。

 

以上

投稿日時:2018年08月03日 16:50   カテゴリー:mariadb   [コメントがあればどうぞ]