You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
dbstudychugoku.github.io 中身の薄い資料で登壇してきた。 speakerdeck.com 具体的な内容が知りたい人は末尾に関連リンクをまとめたのでそっちを見て欲しい。 資料には書いてないけど伝えたかったことをまとめる。 RDBMSの監視の勘所 RDBMSがどれくらいのトランザクションを捌けるかというのが大切な要素の一つ。 単純な処理が多くてキャパオーバーになったとき、多くの場合はインスタンスのサイズを上げるなどのスケールアップで対応できる。 これは費用対効果の高いケースが多く、有効な手段だ。 しかし ロックが原因の場合 はスケールアップしても問題が解決しないことが多い。 例えばバッチ処理で長時間テーブルロックを取り、それが起因でパフォーマンスが問題になっているときは単純なスケールアップで問題は解決しない。 よく見られる処理例は次のようなケース。 トランザクションを開
MySQL JDBC ドライバ(MySQL Connector/J)、Java で MySQL といえばまずコレだが、これまた地味に罠が多い(そして多くの人が踏んで苦しむ)のでまとめてみた。 (2015/03/19) こちら のコメント欄でご指摘ただいた wait_timeout の件について記事修正いたしました。 Summary 以下、いずれもプログラム設計時に理解しておかないと、開発中は大丈夫そうでも実用した途端に苦しまされれてしかも設計から治す羽目になる要注意な罠である: SELECT 結果は全部メモリに載ってしまう (デフォルト設定で) 大量 SELECT する場合は FetchSize, ResultSetType を要設定 利用時には制約があるので、設計段階から考慮しなければならない (後述) idle 時間の「合計で」コネクションが切られる 前回のクエリ処理から一定時間以上経
先日(6/22/14)、6月なのにどういう分けか早めに開催されたJuly Tech Festa 2014でConsulについて発表してきた。そのユースケースの一つとしてMySQL failoverをちょっとだけ紹介したので、ここに詳しく書いておく。 MHA MySQLレプリケーションの障害時にフェールオーバーしたい場合、MHAを使うの結構ポピュラー(日本では)だと思います。MHAは最新binlogの適用、Slaveの昇格とレプリケーションの張替えまではやってくれますが、実際のフェールオーバーの部分はユーザに委ねられていて、master_ip_failover_scriptのテンプレートをカスタマイズするか独自実装する必要があり、一般的な実現方法としてはカタログデータベースの更新かVirtual IPの切替等があります。 Virtual IPだと居残りセッションの問題や切替の保証難しかったり
MySQL binlog API は row based mode でこそ、その真価を発揮する!! 空前の MySQL binlog API ブームですが、みなさん libreplication の examples/basic-[12] を実行するだけで満足してしまっているようです。しかし、libreplication のおもしろいのは examples/mysql2lucene の方なんです。 3つのロギングモード 普段はあまり意識しないかもしれないですが mysql の binlog には statement based, row based, mixed の3種類があります。 statement based は、実際に実行された SQL が記録されます。一部の関数でちょっと危険です。 row based では、実際に変更された行のデータが記録されます。 mixed では、危険な関数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く