LINEのMySQL運用について日本語が正しく表示されていなかったため修正版をアップロードいたしました。 https://www.slideshare.net/linecorp/linemysql-115766814
MySQL関連のパラメータ(主にInnoDB)について - hiroi10のブログ
このエントリはMySQL Casual Advent Calendar 2015の10日目のエントリです。 先日のMySQL Casual Talks Vol8で@karupaneruraさんがパラメータの振り返りのような発表をされていたので、昨今あまり書かれなくなったMySQLに絡む設定パラメータについて書きます。それなりのメモリ(32GBとか)やSSDとか使ってる事を前提にしたような内容となります。 依存して変更した方が良いパラメータもあるので内容が前後に飛びますがご容赦下さい。またソースコードをがっつり読んだわけではなく、ベンチマーク中の挙動から推測している箇所が多分にあります。MyISAMのテーブルがサービス用データベースに同居する事を考慮していません。 結構突貫で書いているので後から微妙に修正する可能性があります。 InnoDBのパラメータ innodb_buffer_pool_
MySQLのスローログ関連のパラメーターが評価される順番
別のエントリー書いてたら、前に誰かに聞かれたなと思ったのでメモ。 スローログが出力されるかどうかの判定は、 1. スローログが有効化されていること 2. log_slow_admin_statements = 0 で除外されるステートメントではないこと 3. (long_query_time以上の時間がかかっている) OR (log_queries_not_using_indexes にマッチする) クエリーであること 4. クエリーのExaminedが min_examined_row_limit 以上であること 5. log_queries_not_using_indexesにマッチしていることが決まっている場合、log_throttle_queries_not_using_indexes で設定された以上の時間が経っているかどうか 意外と4. が知られてなくて、どんなに時間がかかって
Redirecting…
Redirecting… Click here if you are not redirected.
MySQL のテーブル定義から外部キー制約を推測するツールを作った - ブログ・ア・ラ・クレーム
GW 中の自分へのプチ課題として、表題の通りのツール hakagi(葉鍵, Leaf and Key) を作りました。ツール名には特に意味はありません。 github.com テーブル名やカラム名から外部キー制約を張れるような気がするカラムを選出し、制約追加のための ALTER TABLE をするクエリを吐き出したりします。 なぜ作ったのか 外部キー制約は言うまでもなくデータの不整合を避けるのに有用ですが、いくつかの理由からこれを用いない選択肢も存在すると思われます。 この辺りについては以下の記事なども参考にすると良さそうです。 我々(主語が大きい)は何故MySQLで外部キーを使わないのか MySQLで外部キー制約を課すべきか - リジェクトされました 外部キー制約を設けないことによるデメリットも幾つか生じると思っていて、その一つで自分が気になっている点として、「ER 図をツールで自動生成
MyRocks Performance
In this blog post, I’ll look at MyRocks performance through some benchmark testing. As the MyRocks storage engine (based on the RocksDB key-value store http://rocksdb.org ) is now available as part of Percona Server for MySQL 5.7, I wanted to take a look at how it performs on a relatively high-end server and SSD storage. I wanted to check how it performs for different amounts of available memory f
モンストのサーバー負荷との戦い 〜あけおめ2018編〜 / bcu_30_server_9
スマホアプリ「モンスターストライク」のサーバー負荷は、年末年始に1年のピークを迎えます。2018年元旦のサーバー負荷に立ち向かうために実施した対策の一例として、データベースサーバー（MySQL）を安全に水平分割した事例を紹介します。見積もりから計画、実施に至るまでを時系列で振り返ります。
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
firstworks: sql relay - sqlrelay persistent database connection pool pooling proxy load balance balancing odbc oracle mysql msql postgresql sybase db2 interbase sqlite access c perl DBD DBI python php zope ruby tcl java jni unix linux persistant
Featuring... Updated platform, language, and database support Automatic deadlock resolution, split-multi-insert, and upsert modules Simplified authentication Logging and debug improvements The MySQL and PostgreSQL protocol modules enable SQL Relay to speak the MySQL and PostgreSQL client-server protocols, making it a transparent, server-only proxy for MySQL and PostgreSQL databases. How does SQL R
MySQLパラメータ比較 - tmtms のメモ
Vue.js の勉強をしようと思ってMySQLのバージョン間のパラメータを比較できるページを作ってみました。 MySQL Parameters やってることは、あらかじめ mysqld --no-defaults -v --help の出力からパラメータの名前と値を JSON にしておいて、それを表示しているだけです。 環境によってデフォルト値が動的に変わるようなパラメータもあるのですべて信用できるわけではないですけど、まあ参考くらいにはなるかなと。 自分が 5.7 と 8.0 の比較を見てみて気づいたのは、 basedir のデフォルト値が mysqld の実行パスから動的に生成されるようになった。 date-format, datetime-format なんてパラメータが今まであったの知らなかった。 へー query-cache まわりはパラメータ自体なくなったのか…。 とかとか。
GitHub - fireworq/fireworq: Fireworq is a lightweight, high-performance, language-independent job queue system.
Fireworq is a lightweight, high-performance job queue system with the following abilities. Portability - It is available from ANY programming language which can talk HTTP. It works with a single binary without external dependencies. Reliability - It is built on top of RDBMS (MySQL), so that jobs won't be lost even if the job queue process dies. You can apply an ordinary replication scheme to the u
mysqlbinlogでバイナリログをバックアップするとか
mysqlbinlogは今まで（バックアップ用途で）リモートからバイナリログを読ませようとしても、 ・SQLテキスト形式にエンコードした後のものを出力させるだけ。 ・その時点の最後のエントリまでしか読み込めない。 ・出力先ファイル名は1つしか指定できないので、 読み込み元のバイナリログが複数でも出力は1つ。 だったのが、5.6のmysqlbinlogでは ・エンコードする前の状態のまま書き出せる。 ・tail -fぽく待機して、更新があれば続けて書き出せる。 ・ファイル名はマスターのものと同じものにできる。 スイッチしたらmysqlbinlog側のファイル名も変わる。 と、スレーブに--log-slave-updatesを付けた様な動作が出来る様になった。 バックグラウンドにして常駐させておけば、暇そうなサーバにバイナリログをリアルタイムにバックアップ出来る。 マスターから見るとレプリケー
Redirecting…
Redirecting… Click here if you are not redirected.
トランザクション技術とリカバリとInnoDBパラメータを調べた - たにしきんぐダム
トランザクションはACID特性を満たすと言われている。 そのうちA(Atomicity)はトランザクション内の操作をAll or Nothingとなるよう保証し、トランザクションが中途半端に実行されて(アプリケーションレベルから見た)データの整合性が失われることを防ぐ特性。またD(Durability)とはシステム運用中に起こる様々な障害からデータを守る(整合性を保つ)特性。 これらの特性を満たすためのDBMSの古典的なテクニックがすごく面白いので、それに関するMySQL(主にInnoDB)のパラメータ・パフォーマンスにどのような影響を及ぼすかを調べた(*'ω'*) なお紹介している技術は基本的に教科書に書かれていた技術で、実際にInnoDBに実装されているアルゴリズムとは異なることがある(とはいえベースにはなっている) 参考 障害の種類 DBMSの基本構成 データベースバッファ 概要 関
ioMemoryがエンジニアをダメにする!?―MySQLでioMemoryの性能を使い切るためには
日時：2015年10月29日(木) 19:00 - 21:30（開場18:30） 場所：IIJ本社 13F（飯田橋グラン・ブルーム） ※2Fオフィスエントランスで受付後、エレベータで13Fにお越しください。 定員：50名 ※懇親会参加（無料） お申込みはこちら フラッシュストレージは、入れれば速くなるのは本当か？ サンディスク エンタープライズセールス シニアセールスエンジニア 高木 健誠氏 谷川：実際のところフラッシュはただ入れれば速くなるのでしょうか。何らかのフラッシュ向けの設定やチューニングがやはり必要になるのでは。 正原：ベンダーが言うように、とりあえず入れればそれだけで速くなります。とくにストレージに負荷のかかるテストを行えば確実に性能が出ます。一方で、データベースの処理はそのままでもそこそこ速くなりますが、やはり手を入れなければダメな場合も。じつはこのあたりは「やってみないと分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.0 Release Notes
スレッドIDを利用したMySQLのデッドロック解析手法
pixivにおけるMySQL運用の実際
Insert Random Data into Tables Using mysql_random_data_load
さいきんの InnoDB Adaptive Flushing （仮）
