Knownを読んでなかったので読むことにした。そんなに文章量も無いので、以下重要そうなトコだけ抜粋して記述していく。Clusterの組み合わせでいじってるとスグ気がつく部分だと思う。マスターを優先順位を付けて指定したい場合は、こちらの内容を元に対応すると良いだろう。Splittingじゃないと、マスターの切り替えには対応出来ないということなのだろうか。Maxscaleを利用している人は要注意だ。自分も会社で利用していた際に引っかかった所なのだけど、以下の場合だとSQLの内容がSELECTだろうがINSERTだろうが全てマスターノードに寄ってしまうので、処理が分散されない事になる。一つのクエリの中で複数のSQL文がある場合(;で区切っていくつもSQL文を実行している場合)Go言語でいうと、例えばGenmaiとか使ってると、全てのSQLがマスターノードで処理されてしまうということになる。マルチマスタなのに負荷分散されないという、なかなか意味のないクラスタとなるので注意が必要。documentation.一つのクエリ内で複数のSQLを処理している場合、その処理がreadwritesplitrouterを経由している場合、全てマスターノードに振り分けられる事になる。これを解消するには、readwritesplitrouterの設定にオプションとして「strict_multi_stmt=false」を設定する必要があるようだ。この設定を追加することで、複数処理を記述したSQLはマスターにも割り振られるものの、スレーブノード側にもちゃんと割り振ってくれるようになるらしい。<DB名>など)については、1サーバではなくバックグラウンドの全てのサーバにルーティングされるようだ。always.サーバ側のセッション変数はSQL変数として読み込まれ、もしバックグラウンド側にマスターがいるようであれば、SQL変数はマスターでのみ読み書きされる(マスターだけで処理される)。オートコミット値及びプリペアステートメントについては、全てのノードにルーティングされる。プリペアドステートメントを使っている場合、クエリ自体は全てのノードに送られるが、実際の処理はマスターでのみ行われる(処理が偏る)ということになる。all」が設定されている場合、SELECTクエリがユーザー変数を変更した場合、ルーティングされずエラーが返ってくるとのこと。master」を設定するとのこと。MaxScale.MaxScaleでは、MySQLでホスト名にワイルドカードマッチングを使用して認証を管理することはできない。(IPアドレスでのワイルドカードは利用可能)MySQLバージョン4.1以前のパスワードは対応していない。接続しにいくノードのユーザ名とパスワードは、全て同一である必要がある(ノードごとに異なるパスワードは設定出来ない)。database.Schemarouterでは、以下のような制限があるらしい。クロスデータベースクエリはサポートしていない。2つ目以降のデータベース指定は全て最初に指定したデータベースにルーティングされる。デフォルトデータベースがないと、明示的なデータベース指定の無い、セッション状態を変更しないクエリは、最初に使用可能なサーバへルーティングされる。均一な結果を保証できないため、セッション変数を変更するようなSELECTクエリは現在サポートされていない。schemarouterは、クエリがデータベースをターゲットにしている場合はクエリが最初に使用可能なサーバーにマッピングされていません。大体合ってるだろうか。基本、Maxscaleを利用している場合の大半はReadWriteSplittingを用いる事が多いだろうと思う(個人的な感想)ので、その辺りの制限についてはちゃんと読んでおいた方が良さそうだ。blacknonインフラエンジニア(...のつもり)。仕事で使うならクライアントはWindowsよりはUNIXの方が好き。Commentコメントをキャンセルメールアドレスが公開されることはありません。