tag:blogger.com,1999:blog-1906500952232920237.post2620670247322071696..comments2024-03-04T07:17:06.934+09:00Comments on 漢(オトコ)のコンピュータ道: 隙がなくなったMySQL Cluster 7.3登場!!これで勝つる。Mikiya Okunohttp://www.blogger.com/profile/15996977664356830358noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1906500952232920237.post-13306649025328748702013-11-03T23:00:56.986+09:002013-11-03T23:00:56.986+09:00Ishizaka Takehiko さん
コメントおよび電子書籍の購入ありがとうございます。
書...Ishizaka Takehiko さん<br /><br />コメントおよび電子書籍の購入ありがとうございます。<br /><br />書籍のほうではp.32からの解説がこのこのブログ記事の内容に該当するのですが、少し書き足りない感じがしますね。改訂があれば加筆したいと思います。Mikiya Okunohttps://www.blogger.com/profile/15996977664356830358noreply@blogger.comtag:blogger.com,1999:blog-1906500952232920237.post-38938404589188578832013-11-01T06:12:19.664+09:002013-11-01T06:12:19.664+09:00PDF版の書籍をGETしました。
http://gihyo.jp/book/2012/978-4-7...PDF版の書籍をGETしました。<br />http://gihyo.jp/book/2012/978-4-7741-5053-6<br /><br />SQLノードへDBクライアントからの構成例があるとイメージしやすいなぁと思いました。今のところ、SQLノードとDATAノードとDBクライアントを物理1サーバに1セットにしようと思っています。迷っているのは、DBクライアントからSQLノードへのアクセスをlocal接続(UNIXソケット)にすべきか、上記のLBの仮想IPにて分散させるかです。この図が大変イメージしやすかったです。<br />http://nippondanji.blogspot.jp/2009/02/mysql-cluster.htmlJunkHackhttps://www.blogger.com/profile/01341564660928265374noreply@blogger.comtag:blogger.com,1999:blog-1906500952232920237.post-71519511678766423722013-06-26T08:17:53.940+09:002013-06-26T08:17:53.940+09:00書籍の購入ありがとうございます。
取得するべきなのは「スロー」クエリログです。まずはロックを掴みっ...書籍の購入ありがとうございます。<br /><br />取得するべきなのは「スロー」クエリログです。まずはロックを掴みっぱなしにしてるUPDATE等がないかどうかを調べるのが王道ですね。あと、この記事にあるように、7.3にアップグレードするとクエリの効率が向上するのでオススメです :)Mikiya Okunohttps://www.blogger.com/profile/15996977664356830358noreply@blogger.comtag:blogger.com,1999:blog-1906500952232920237.post-17780760841682537372013-06-26T00:05:19.998+09:002013-06-26T00:05:19.998+09:00コメントありがとうございます。
いろいろバッファ関連を増やしたりしてみましたが全く変わらない様なので...コメントありがとうございます。<br />いろいろバッファ関連を増やしたりしてみましたが全く変わらない様なのでquery logを取得してみんなで確認してみたいと思います。<br /><br />Google Books版の「MySQL Cluster構築・運用」を個人でも購入させていただきました。<br /><br />奥野様もご健勝で頑張ってください。Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1906500952232920237.post-89493947666179980742013-06-24T20:39:42.762+09:002013-06-24T20:39:42.762+09:00Hashimura Masayuki さん、コメントありがとうございます。
Lock waitはD...Hashimura Masayuki さん、コメントありがとうございます。<br /><br />Lock waitはDBTCが制限時間内に対象の行に対するロックを獲得できなかった場合に発生するエラーです。行レベルロックに対するデッドロックがおこったり(NDBにはInnoDBのようなデッドロック検知機能はありません)、長時間かかるクエリがロックを解放しなかったり、DBTCとは異なるノードにあるレコードをロックする必要がある場合にネットワークがとても遅くなっていたりといった原因が考えられます。<br /><br />要因は様々ですので、概要を聞いただけではなんとも判断し難いところがあります。上記のような要因がありますので、目星をつけてあたってみてください。まずはスロークエリログあたりからでしょうか。Mikiya Okunohttps://www.blogger.com/profile/15996977664356830358noreply@blogger.comtag:blogger.com,1999:blog-1906500952232920237.post-30545910110304811932013-06-24T05:46:19.021+09:002013-06-24T05:46:19.021+09:00奥野さま、
構築・運用バイブルでいつも助けられています。
いままで何とかしのいできたのですが
...奥野さま、<br /><br />構築・運用バイブルでいつも助けられています。<br /><br />いままで何とかしのいできたのですが<br /><br />mysqld: Sort aborted: Lock wait timeout exceeded; try restarting transaction<br /><br />が定期的に20分毎に発生する症状に悩まされています。<br /><br />mysql-5.5.29 ndb-7.2.10を使っていて、データノード4台、SQLノード8台ほどで、いつもトータルで10000qps、アップデートで1000qps程度で動いていますが、この辺りを超えると<br />全部のSQLノードで上のメッセージが出てSQLノードがオフライン・オンライン状態になってサービスが再度開始される状態になります。<br /><br />20分ほどというキーワードがカギのようなのですがどうも原因がわからずに困っています。<br /><br />なにかチェックしたらいい点等はありますでしょうか。<br /><br />TransactionDeadlockDetectionTimeout=2400<br /><br />と増やしてみましたがまったく変わりませんでしたし、データノードは最大でもCPU利用率が5%程度でアイドル状態です。ただ、仮想サーバでの稼働ということでndbdを使っています。<br />Anonymousnoreply@blogger.com