技術めも

mysqlではインデックスは1つしか使えないと言われていたが、

実際はインデックスマージという機能があるため、

2つ同時に使うことは可能である。

ただ、インデックスマージはwhere句でのみ作用可能に思われるので、

whereとorder byで違うインデックスを使うのは無理なのではないかと思っている。

MySQL5.7でもMariaDB10.2でも、このあたりの記述が見当たらなかった。。

上記の理解であっているのか、非常に気になるところである。

進展があったら、書こうと思う。

以上

fluentdとelasticsearchを長時間つないでいると、

「Cannot get new connection from pool.」というエラーが出る。

これが出ると、fluentdを再起動しなければならなかった。

そのため、logrotateでfluentdを再起動して、この問題を回避していた。

この現象が出るfluentdのプラグインのバージョンは以下の通りであった。

（たぶん、これより古いバージョンでも出てたのでは）

• elasticsearch : 1.1.pre
• elasticsearch-api : 1.1.pre
• elasticsearch-transport : 1.1.pre
• fluent-plugin-elasticsearch : 1.9.2

上記を以下のバージョンに変更したところ、コネクションエラーは一切起きなくなった。

• elasticsearch : 5.0.4
• elasticsearch-api : 5.0.4
• elasticsearch-transport : 5.0.4
• fluent-plugin-elasticsearch : 1.9.5

念のためresurrect_afterという設定も入れてはいる。

一応、これで1か月以上再起動かけなくても、エラーは出なくなった。

ちなみに、elastic search本体のバージョンは5系である。

以上

GaleraClusterでは、書き込みノードを1つに絞って、

デッドロックを回避したほうがいいとよく言われる。

maxscaleを使えば、書き込みノードを絞ることは簡単であるが、

単に3つのクエリーを実行するだけで、書き込みノードを絞れるので、記載しておく。

なお、Perconaも似たような方法をやっていた。

１．SHOW GLOBAL STATUS LIKE 'wsrep_local_state';　の結果が4である

２．SHOW VARIABLES LIKE 'read_only';　の結果がoffである

３．SHOW GLOBAL STATUS LIKE 'wsrep_local_index';　の結果が0である

以上、3つを満たした場合、書き込みノードとして判定してOK。

haproxyと組み合わせることも簡単なので、

どこかでhaproxyとの組み合わせについても記載しようと思う。

以上