MySQL Connector/J を利用するときは cacheServerConfiguration=true を設定する - tokuhirom's blog
MySQL は一般に接続コストが低いことで知られており､コネクションプーリング等しなくても使えるので便利｡ だが､Java 用の MySQL Driver であるところの MySQL Connector/J はデフォルトでは数個のクエリを接続時に発行しており､デフォルトのままでは無駄に負荷がかかる｡ デフォルトでは以下のように4つの準備クエリが発行される! どう考えてもおかしいですよね!やばいっす! 150108 9:18:11 5 Connect root@localhost on test 5 Query /* mysql-connector-java-5.1.34 ( Revision: [email protected] ) */SHOW VARIABLES WHERE Variable_name ='language' OR Variable_name = 'net_write_
うるう秒のあとにMySQLなどのCPU使用率が高騰する件について - SH2の日記
2012年7月1日のうるう秒のあとに、MySQLやJavaなどのCPU使用率が高騰する事象が報告されています。 CPU %user %nice %system %iowait %steal %idle 08時30分01秒 all 0.02 0.00 0.02 0.04 0.00 99.91 08時40分01秒 all 0.02 0.00 0.02 0.08 0.00 99.88 08時50分01秒 all 0.02 0.00 0.02 0.03 0.00 99.92 09時00分01秒 all 0.11 0.00 0.13 0.04 0.00 99.72 09時10分01秒 all 23.02 0.00 29.09 0.11 0.00 47.78 09時20分01秒 all 23.11 0.00 29.08 0.06 0.00 47.75 09時30分01秒 all 22.85 0.00
『MySQLバイナリログパーサJava実装』
みなさん、はじめまして。新規開発局で基盤系システムを担当している、歴史学科出身のH.T.です。 このブログ用に新規にレポートおこす人もいるようですが、私はちょっとたてこんでいるので第4回研究レポートからの抜粋です。ご容赦ください。 はじめに「MySQLのバイナリログからSQL文を抽出したい、しかもJavaで」と思い、バイナリログのパーサをJavaで実装しました。 MySQL 4.1で使われているv3フォーマット、かつステートメントベースのレプリケーションを前提にしています。 バイナリログの構造バイナリログの構造を理解するにあたっては、MySQL Forge WikiのMySQL Internals Binary Logの項を参照しました。 バイナリログは、ひとつのマジックナンバーと複数のイベントで構成されています。マジックナンバーはファイルの先頭にひとつだけ存在する、4byteの固定長デー
MySQL JDBC Connector/J + DBCP + Spring framework (+Spring Security)でDB再接続時に例外発生 - けみかるはてな
MySQL+DBCPでDB接続するときは、DB接続タイムアウト時の対策として検証クエリを入れましょうというお話。 現象 MySQLのサーバパラメータ "wait_timeout" の秒数(デフォルト:28800秒 = 8時間) を超過してDBに再接続しようとすると以下の例外が発生した。 org.springframework.security.AuthenticationServiceException: PreparedStatementCallback; SQL [SELECT user_id, password, role_id FROM user WHERE user_id = ?]; The last packet successfully received from the server was 54,586,800 milliseconds ago. The last pac
BasicDataSourceFactoryのvalidationQueryに指定するのに適していそうなクエリ - HHeLiBeXの日記 正道編
ApacheのCommons DBCPに含まれるorg.apache.commons.dbcp.BasicDataSourceFactoryでは、validationQueryというのを指定できるが、ここで指定するクエリにはいくつかの条件がある。 SELECTクエリであること 1つ以上の行を返すこと 1つ以上の列を返すこと したがって、例えば、"SELECT COUNT(*) FROM xxx"みたいなクエリは条件を満たすが、コネクションの検証のためだけに重たくなるかもしれないクエリは投げたくない。 そこで、DB2、Oracle、PostgreSQL、MySQLについて、validationQueryに適していそうなクエリを作ってみた。 なお、括弧内は動作確認に使用したDBMSのバージョン。 DB2 (v9.1, v9.5)*1 SELECT * FROM TABLE(VALUES(1))
サンの買収が承認された日、ブログにお墓を描いたゴスリング
1月21日、欧州員会はオラクルによるサン・マイクロシステムズの買収を承認しました（米オラクルによるプレスリリース)（Wordファイル））。 その同じ日、サン・マイクロシステムズでJavaの生みの親とも言われるジェームス・ゴスリング氏はブログにサン・マイクロシステムズのお墓の絵を載せていました。 Linuxのマスコットであるタックスと、Javaのマスコットであるデュークが手を合わせている墓石には「The Network IS」と刻まれているようです。 この翌日、ゴスリング氏はブログで次のように書いています。 OK, it's time to look forward... Enough of being maudlin, it's time to look forward to being a unified company: オーケー、前を向くときが来た もう十分泣き続けた、1つの企業とし
ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
Connector/JのSQLインジェクション脆弱性 - SH2の日記
PreparedStatement使ってるのにSQLインジェクションが起きるんですけど？という話題。徳丸浩の日記 - JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性より。 再現したのでバグレポート投げておきました。MySQL Bugs: #41730: SQL Injection when using U+00A5です。すてきなパッチで解決されることを期待したいと思います。 うちの社内でcharacterEncoding使ってるところはないから大丈夫なはず…。と思っていたのですが、ブクマコメントをいただいたとおり、character_set_server=cp932の設定がされたmysqldにcharacterEncodingなしでつないだ場合もインジェクションを起こせますね。sjisもujisもeucjpmsもダメです。というわけで、
Connector/J 5.1とServer Side Prepared Statement - mir the developer
ここ数日「MySQL + Connector/J(JDBCドライバ) + プリペアードステートメント」の話題がちらほら出ています。正確に把握はしていないですがSQLインジェクション対策→PreparedStatementという流れできた話のようです。 徳丸浩の日記 - JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 へぼへぼCTO日記 - useServerPrepStmtsを使うのが根本解決だとはおもう。けど…？ id:kazuhookuのメモ置き場 - MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 自分は元Connector/J開発メンバ(※インターン生として)でもありとても気になる話題なので、Connector/Jのソース解析も含めた説明をここで行いたいと思う。 プリペアードステートメント
MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 - kazuhoのメモ置き場
useServerPrepStmtsのここの説明ではデフォルトがtrueになっているが、これは上述の通り嘘である。 (中略) そしてなぜfalseにされたかということの背景を察すると、trueにすることの弊害もありそうで、手放しでこれをtrueにすることを勧めることが少しはばかられる。 http://www.geminium.com/chiba_blog/2008/12/23/33/ 自分は Java 使ってないですが、MySQL の中の人が使うなって言ってます *1。その理由はメモリリークのような症状が出る可能性があるから。 So why are prepared statements a problem? Because users do not clean up/close unused prepared statements. Multiply the number of prep
JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2008年12月22日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 今年のBlack Hat Japanには、はせがわようすけ氏が「趣味と実益の文字コード攻撃」と題して講演され話題となった。その講演資料が公開されているので、私は講演は聞き逃したが、資料は興味深く拝見した。その講演資料のP20以降には、「多対一の変換」と題して、UnicodeのU+00A5（通貨記号としての￥）が、他の文字コードに変換される際にバックスラッシュ「\」（日本語環境では通貨記号）の0x5Cに変換されることから、パストラバーサルが発生する例が紹介されている。 しかし、バックスラッシュと言えばSQL
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
