stackprof の wall mode で rails のプロファイルをとろうとしたら mysql の接続エラーがたくさん出てホストが mysql にブロックされてしまう話 - エンジニアですよ！
起きたこととしては stackprofをrack-stackprofで使って rails アプリのプロファイルを取ろうとした stackprof は wall mode で動いてる すると、Host 'x.x.x.x' is blocked because of many connection errors が発生した 起動後しばらくは正常に動いているが、しばらくするとエラーが連続して発生してしまうようで mysql サーバにブロックされアプリが動かなくなる。 原因は stackprof は profile を取るために setitimer で定期的にシグナルを送る wall モードの場合、 setitimer が ITIMER_REAL で動くので、実時間で定期的にシグナルを送る。 libmysql は mysql に接続後 poll でデータを待ち受ける。 poll で待っている間にシ
VOYAGE GROUP エンジニアブログ : MySQL InnoDBのinsertとlockの話
2015年03月08日17:06 カテゴリ MySQL InnoDBのinsertとlockの話 こんにちは。ECナビでアプリケーションエンジニアをやっている駒崎です。 今回はMySQLのInnoDBエンジンにおけるINSERTとロックの挙動について書きたいと思います。 はじめに アプリケーションでレコードの重複チェックをしてからINSERTをする。テーブルにはUNIQUE制約をかけてデータ不整合が起きないようにしている。という仕様はよくあるケースだと思います。 こういったケースでINSERTしたときにどのような仕組みが働いて重複データを防いでいるのだろう？アプリケーションで重複チェックをしてはいるけどMySQLではどんな挙動をしているんだろう？というのが気になったので調べました。 調べること INSERTした場合のロックの挙動 FOR UPDATE文で排他ロックをかけた場合のロックの挙動
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.2.1.6 インデックスコンディションプッシュダウンの最適化
インデックスコンディションプッシュダウン (ICP) は、MySQL がインデックスを使用してテーブルから行を取得する場合の最適化です。 ICP を使用しない場合、ストレージエンジンはインデックスをトラバースして、ベーステーブル内で行を検索し、MySQL Server に返し、MySQL Server が行に対して WHERE 条件を評価します。 ICP が有効で、インデックスのカラムのみを使用して WHERE 条件の一部を評価できる場合、MySQL サーバーは WHERE 条件のこの部分をストレージエンジンにプッシュダウンします。 ストレージエンジンは、インデックスエントリを使用して、プッシュされたインデックス条件を評価し、これが満たされている場合にのみ、テーブルから行を読み取ります。 ICP は、ストレージエンジンがベーステーブルにアクセスする必要がある回数と、MySQL サーバーがス
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
MySQL 5.5.11 unicode_ci で同一視される文字
MySQL 5.5.11 unicode_ci で同一視される文字 Unicode 002000A02000200120022003200420052006200720082009200A202F205F3000 Character Unicode 0021FE57FF01 Character !﹗！ Unicode 0022FF02 Character "＂ Unicode 0023FE5FFF03 Character #﹟＃ Unicode 0024FE69FF04 Character $﹩＄ Unicode 0025FE6AFF05 Character %﹪％ Unicode 0026FE60FF06 Character &﹠＆ Unicode 0027FF07 Character '＇ Unicode 0028207D208DFE35FE59FF08 Character (⁽₍︵﹙
InnoDBの制限とファイルフォーマットAntelopeとBarracudaの違い - かみぽわーる
この投稿はMySQL Casual Advent Calendar 2014の5日目の記事です。 @kamipo 質問させてください。このエントリーで COMPRESSED ではなく DYNAMIC を選んでいる理由はなぜですか？あまりDB詳しくないので参考リンクなどポインタを教えていただけるだけでも構いません http://t.co/9sC4lzLjXr— kiyoshi nomo (@kysnm) November 27, 2014 先週ツイッターでInnoDBのことを質問されまして、せっかくなのでアドカレのネタにしようと思いますってことでInnoDBのファイルフォーマット毎の違いをカジュアルに説明しようと思います。 InnoDBのファイルフォーマットBarracudaと新機能 InnoDBにはファイルフォーマットとして昔からあるAntelopeと新しいフォーマット(5年も前からあるの
ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32 - Garbage in, gospel out
起きたこと ローカルマシンから mysql につなごうとしたら以下の様なエラーが発生し繋げなくなった。 $ mysql -uroot ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32 原因 1 process あたりの許容ファイルオープン数を超えてしまったことが原因の様子。 MySQL 5.6 の innodb_file_per_table オプションはデフォルトで ON になっている。 ON にすると各テーブルのデータはそれぞれのファイルに保存されるようになる。 OSX の場合、1 process あたりの許容ファイルオープン数はデフォルトで 256 となっている。 この数字は通常問題にならないが、 parallel に
MySQL5.6がメモリを沢山お召し上がりになる件
EC2のt1.microでMySQL 5.6.12を入れて試してみたところ F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 4 498 4594 4407 20 0 950456 434320 poll_s Sl pts/0 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/lib/mysql/xxx.pid な感じで、インストール直後ただ起動しただけで400MB超のメモリをお召し上がりになってしまっています マイクロインスタンスにとってはこのメモ
二千万レコードあるテーブルへのalterをサービスを止めずに流す | All Your Bugs Are Belong To Ass
※このエントリはMySQL Casual Advent Calendar 2015の5日目のエントリです。 openark-kit というものについて ここまで読んでわかった方は、この先を読む必要はありません。 openark-kitとは、mysqlの運用に便利なツールキットを14個あつめたソフトウェアパッケージです。 Shlomi Noachという方がPythonで開発しており、少なくとも2009年に発表されているようです。 2015-12-05時点での最新版は196.1となっており、.tar.gz および .deb で配布されております。 このエントリを書いた背景事情 そもそも僕自身、50を超えるクラスタ化されたmysqlノードと一緒に業務生活を送っております。 ところが、システムが非常に古くさい構成のため、合計レコード数が2億から3億程度ある垂直分割されたテーブルに対しALTERを投
MySQLで処理に長時間かかっている複数クエリをまとめて殺す方法 | Basicinc Enjoy Hacking!
あまりにも処理に時間がかかるようなSQLを実行してしまい、MySQLがうんともすんとも言わなくなってしまうような状況、よくありますよね。っていうか、まぁそんな状況あってはならないんですが、時たまあります。そんな時、問題となっているクエリの処理を止めたいわけです。 特定のクエリを止める方法 MySQLで実行中のクエリ一覧を見て、SQLを強制終了する方法 こちらを見てもらえればやり方は分かります。単純にMySQLに入って、show processlist;で問題のあるクエリを発見し、プロセスIDを kill するだけ。とても簡単。 複数のクエリを一括で止める方法 今回は問題のあるクエリが100個あったらどうする…？的なのを解決するエントリーです。まぁ、問題あるクエリ100個ある状況は、アプリ的に問題あるんじゃね？っていうレベルですが。 1個ずつプロセスIDをコピペして…なんてやってられないです
シンプルで移行しやすいデータベースシャーディング - クックパッド開発者ブログ
技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！）
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！） 【2016/01/13 10:12】 MySQL 5.7.11でdefault_password_lifetimeのデフォルトは0に変更になりました！ それ以降のバージョンであればこの記事の内容は気にする必要はありません。 日々の覚書: MySQL 5.7.11でdefault_password_lifetimeのデフォルトが0になるらしい！ TL;DR default_password_lifetime= 0 を秘伝のmy.cnfに入れておくつもり。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables パラメーターの意味は読んで字のごとく、「最後にパスワードが更新さ
MySQL-5.5/5.6でのレプリケーション利用者に伝えたい「RESET SLAVE」にまつわる怖い話 - Y-Ken Studio
MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を 発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。 さらに、RESET SLAVE ALL;というクエリもサポートされたようです。 どういう事なのでしょう？ 調べてみました。 ドキュメントにさらっと何か書いてある In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. Thi
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） こんにちは nob です。 前編 これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） の記事から１年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を（システム編）としてお届けいたします！ 今回の（システム編）で紹介するツボは 4 つです。（クエリ編）のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 （ツボ１）Load Average < (1 + (cpu数-1)/3) （ツボ２）Checkpoint Age が水平線になったら要注意 （ツボ３）MyISAM は無いよね監視 （ツボ４）万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
免费送彩金官方网站-免费高清完整版
rails4 でバルクアップデート : sonots:blog
http://enomotodev.github.io/post/use-goose/
Osc2015北海道 札幌my sql勉強会_波多野_r3
30ごえのWEBエンジニアの日記:MySQLのshow processlistを特定の条件でフィルタリングしたい
MySQLの運用でありがちなこと
