Configuration properties define how Connector/J will make a connection to a MySQL server. Unless otherwise noted, properties can be set for a DataSource object or for a Connection object. Configuration properties can be set in one of the following ways: Using the set*() methods on MySQL implementations of java.sql.DataSource (which is the preferred method when using implementations of java.sql.Dat
この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの
You’re seeing information for Japan . To see local features and services for another location, select a different city. Show more Uber Engineering’s Schemaless storage system powers some of the biggest services at Uber, such as Mezzanine. Schemaless is a scalable and highly available datastore on top of MySQL¹ clusters. Managing these clusters was fairly easy when we had 16 clusters. These days, w
Facebook、新しいMySQL用ストレージエンジン「MyRocks」をオープンソースで公開。フラッシュに適したデータの書き込みと圧縮効果 FacebookはMySQL用の新しいストレージエンジン「MyRocks」をオープンソースで公開しました。同社のエンジニアである松信嘉範（Yoshinori Matsunobu）氏がFacebookのブログに投稿した記事「MyRocks: A space- and write-optimized MySQL database」で紹介しています。 MySQLのデータベースエンジンとして使われているInnoDBは優れているものの、フラッシュストレージと組み合わせたときに書き込まれるデータ量の効率性などに課題があったため、MyRocksに取り組んだと説明されています。 InnoDB is great for performance and reliabil
tech.kayac.com Advent Calendar 2015 8日目担当の @m0t0k1ch1 です。 今年は MySQL さんにいろいろ泣かされた1年でした。特に、あの夏、幾夜をともにした実行計画のゆらぎは一生忘れな(ry さて。。。今回は、そんな中でも誰もが一度は嵌るであろう（？）MySQL（InnoDB）の REPEATABLE READ の嵌りどころについて自分なりにまとめてみようと思います。 この記事が目指すこと MySQL の各トランザクション分離レベルの嵌りどころについては、現状でも種々のブログ記事などでまとめられており、そんなに真新しい話ではないと思います。が、過去の自分のように、嵌ったことがない人間からすると、 話としてはなんとなく理解できる が、抽象的でいまいち身につかない というのが現実でした。嵌りどころに実際に嵌った今読み返してみると、「あーーー、、、そ
はじめに 藤本です。 Elasticseachに取り込むネタが続いています。 前回のELBのアクセスログをAWS LambdaでElasticsearchに取り込むに続いて、今回はRDS for MySQLのスロークエリログをElasticsearchに取り込む実装をご紹介します。 概要 MySQL Serverはスロークエリーログにより指定した秒数を超えるクエリを記録することができます。スロークエリログはパフォーマンス劣化の解析、クエリの適切性、DBのマシンパワーの適切性のチェックに役立ちます。RDS for MySQLも例外ではありません。パラメータグループを設定することにより、スロークエリログを有効にすることができます。それに加えてRDS for MySQLの場合、AWSのAPIによりデータベースに接続せずともスロークエリログを取得することができます。 スロークエリログフォーマット
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
DBT-2 で MySQL と他のRDBMSの性能比較をしている人に騙されないように注意
一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。 未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。 DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。 が、３年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘して
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
InnoDBにはデータの圧縮機能がありますが、パフォーマンスが低いことからあまり使われていません。ただ今年の Percona Live で Oracle MySQL, MariaDB, そして Percona Server が新しい InnoDB Compression を出してきました。これはFusion-ioの R&D チームがフラッシュストレージ向けの MySQL 高速化の一環で開発したパッチが元になっています。ちなみに私は Fusion-io の社員ですのでこの発表をワクテカして待っていたのですが、折角コードが一般にリリースされたので、ソースコードを眺めて動作を調べることにしました。 参考にしたのは MySQL Server Snapshots (labs.mysql.com) にある MySQL with InnoDB PageIO Compression のソースコード、および
こんばんは。 MySQL Casual Advent Calendar 2011 5日目担当のid:marqsです。 東京は12月6日になってしまったかもしれませんが、京都は霊力が強いせいかまだ12月5日のようです。 MySQLにまつわるCasualなネタ、なかなか思いつかなかったのですがちょっと前に調べたInnoDBのテーブル統計情報について書いてみます。 InnoDBのテーブルのインデックス統計情報ですが、基本的に以下のタイミングで更新されます。 テーブルがオープンされたとき テーブル統計の情報が更新された後、テーブルの全行数の1/16が更新されたとき テーブル統計情報の更新後、20億行以上の行が更新されたとき ANALYZE TABLEが実行されたとき SHOW TABLE STATUS, SHOW INDEX FROM …が実行されたとき この統計情報の更新処理ですが、@nippo
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
一日に数回 MySQL が詰まるような現象があったので原因を調べたところ、そのサーバだけ innodb_stats_on_metadata=1 になっていたのが原因だったという話デス。 innodb_stats_on_metadata は、テーブルのメタデータにアクセスしたときに InnoDB の統計情報を更新するかどうかのフラグで、今回問題が起こっていたサーバのようにデータ量が多いサーバなどでは無効にしておく必要があります。例えば、公式ドキュメント の innodb_stats_on_metadata の部分にはこのように書いてあります。 この変数が有効 (この変数が作成される前からのデフォルト) な場合、SHOW TABLE STATUS や SHOW INDEX などのメタデータステートメントの実行時や、INFORMATION_SCHEMA テーブル TABLES または STATI
LinuxのMySQLサーバで最低限やっておかなくてはならないファイルシステム、メモリ、CPUに関する設定のメモ。 December 7, 2013 By Alexander Rubin 恐らくほとんどのMySQL本番環境はLinux上で動いていることだろう。なので、MySQLのパフォーマンスを上げるのに有用な、最も重要なLinuxのチューニングのためのヒントについて書こうと決めた。特に新しい情報はなくて、どれもよく知られているものではあるが、ブログ記事にまとめてみる。 ファイルシステム ext4 (またはxfs) をnoatimeオプション付きでマウント スケジューラはdeadlineかnoop # echo deadline >/sys/block/sda/queue/scheduler grub.confに"elevator=deadline"を追加 (詳細はLinuxスケジューラと
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
ツイート今日は、超久しぶりに MySQL Community な勉強会、 MySQL Cluster Casual Talks : ATND に行ってきましたので、今日はそのレポートをしようと思います。 さすがの @nippondanji 節炸裂と @tsakurada さんの運用経験談が最高に楽しい勉強会でした。 まずアジェンダは以下のとおりとなっていました。 【アジェンダ】 Main Sessions: 19:00 – 19:30 @RKajiyamaさん MySQL Cluster大地に立つ！「5.6とは違うのだよ、5.6とは！」 19:30 – 20:00 @nippondanjiさん カジュアルにMySQL Clusterを使ってみよう 20:00 – 20:30 @tsakuradaさん MySQL Clusterと丸４年の付き合いを振り返ってのよもやま話と、 Version
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
All of Percona’s open source software products, in one place, to download as much or as little as you need.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
