https://developer.hatenastaff.com/entry/2019/01/15/120431
mita2 DB メモ: MySQL 8.0でレスポンスタイムのヒストグラムが見れるようになった
このエントリーはMySQL Casual Advent Calendar 2018の7日目です。 自分は筆が遅く、11月から準備しようしよう、と思ってたにも関わらず、結局、直前になって書いてます。。。 さて、MySQL 8.0になって、performance_schemaが15個増えてました。 5.7では、87個。 mysql> select count(*) from information_schema.TABLES where TABLE_SCHEMA = 'performance_schema'; +----------+ | count(*) | +----------+ | 87 | +----------+ 1 row in set (0.02 sec) 8.0では102個。 mysql> select count(*) from information_schema.TAB
光のMySQL 5.7
14. MySQL 5.7について 2013年4⽉に5.7.1-m11(Development Milestone Release, ベータ版) 2015年8⽉に5.7.8-rc2(Realease Candidate, リリース候 補版) 2015/09/08現在、GA(General Available, ⼀般公開版)は まだ 5.6のGA時点で「Oracleとしては18〜24か⽉で次のメジ ャーバージョンをリリースする予定」と⾔っていたので、結 構ズレこんでいるのは確か 13/85 15. MySQL 5.7の新機能 MySQL :: MySQL 5.7 Reference Manual :: 1.4 What Is New in MySQL 5.7 MySQL :: MySQL 5.7 Release Notes Complete list of new features in M
MySQL 5.7の新機能完全リスト | Yakst
MySQL 5.7には150を超える新機能がある。 MySQLのマニュアルはとてもいいものだが、少し長すぎる。これは、新機能の箇条書きリストだ。それぞれの機能について1つずつまとめるように頑張ってある。なので、 InnoDBのネイティブパーティショニング については、InnoDBの項かパーティショニングの項のどちらかにだけ載っている。 MySQL 5.7.8 RC2はここからダウンロードできる それか、yumかaptのリポジトリーからもインストール可能だ。 レプリケーション関連 マルチソースレプリケーション(訳注: 1スレーブに複数マスターを設定可能になった) [ 1 ] オンラインでのGTIDの有効化 [ 1 2 3 ] 準同期レプリケーションの性能向上 [ 1 2 ] ロスレス準同期レプリケーション [ 1 2 ] 準同期レプリケーションでいくつのスレーブからACKが返ってくるまで待つ
InnoDBにおける仮想列および効果的な"関数インデックス"(MySQL Server Blogより) | Yakst
4月にlab版だった仮想列関連の機能がMySQL 5.7.8で公式となった。主な機能についての振返りと、いくつかの簡単な性能テストの結果をお伝えする。 免責事項 この記事はJimmy Yang氏によるMySQL Server Blogの記事「Virtual Columns and Effective Functional Indexes in InnoDB」(2015/8/11)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 4月に私はブログ投稿を行い、JSONのlab版リリースへの新しいInnoDBの仮想列および効果的な関数インデックスについて紹介した。現在ではMySQL 5.7.8で機能は公式なものとなっている。5.7のリリース候補版に何があるのかを記し、追加の例を示すにあたりその話題は再度確認する価値がある。いくつかの簡単な性能テストも実施しており、テーブルへの
GitHub - soundcloud/lhm: Online MySQL schema migrations
Rails style database migrations are a useful way to evolve your data schema in an agile manner. Most Rails projects start like this, and at first, making changes is fast and easy. That is until your tables grow to millions of records. At this point, the locking nature of ALTER TABLE may take your site down for an hour or more while critical tables are migrated. In order to avoid this, developers b
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
MySQLがオンラインALTER TABLEでOOM Killerに殺されたはなし | GMOメディア エンジニアブログ
こんにちは、DBAです。 MySQL5.6のオンラインALTER TABLEでハマった時のおはなしです。 5.6にはオンラインALTER TABLE関連のパラメーターに innodb_sort_buffer_size というものが追加されており(5.5以前はfast index creationが効く時に使われるパラメーターとして内部的に1Mでハードコードされていたものが、設定可能になった)、前にざっくり試したところ 大きくすれば一応それなりの恩恵は受けられそうなので大きくしたんですよ。 毎日の定期バッチで盛大にInnoDBのテーブルにバルクインサートをかけた後にALTER TABLEでインデックスをくっつけてRENAME TABLEでテーブルを切り替える…なんてことをやっているサービスには打ってつけだと思ったわけです（そもそもそのやり方の善悪について やがて DBAは 考えることを止めた
MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ
もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました（と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです） 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその
気軽なMySQLバージョンアップ - まめ畑
このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル！ このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。 MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。 新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。 検証 実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流して
MySQLでMyISAMからInnoDBに乗り換える際に知らないとハマる、怖い話 - Y-Ken Studio
photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
MySQL 5.6への完全移行を実現したTritonnからMroongaへの移行体験記
2013年11月29日に開催された「全文検索エンジンGroongaを囲む夕べ 4」での発表資料です。 イベントページ http://atnd.org/events/43461 Ustream動画 http://www.ustream.tv/recorded/41205740Read less
MySQL5.6関連情報まとめ
5. バグ情報など GTID有効でネットワークが途切れるとデータ消失する InnoDBmemcacheAPIのメモリリーク（ #68530 ） GRANT文発行時、構文に特定の記載ミスがあるとレプリ ケーションが停止する（ # 68892） マッチしないパーティションがたくさんある場合、予想ス キャン件数を過剰に低く見積もってしまう不具合 ※上記は勉強会で見かけた情報などです 僕らのMySQL5.6移行記(仮) http://www.slideshare.net/conmame/mysql56-27565355 7. 運用方法の変化について GTIDが有効だとSlaveでクエリをスキップできなくなって確認 して空コミットしないといけなくなった（割と手間） MySQL Utilityというpythonツールが便利そう バッファプールのダンプとリスト
Facebookが何千台ものMySQLを人手を使わず自律管理する仕組み「MySQL Pool Scanner（MPS）」
おそらく世界でもっとも大規模にMySQLのクラスタを展開し、運用しているのがFacebookでしょう。複数のデータセンターにまたがり何千台ものMySQLサーバを運用するために、自動化の仕組みは欠かせません。 その自動化がどのような仕組みになっているのか。FacebookのデータベースエンジニアであるShlomo Priymak氏が、Under the hood: MySQL Pool Scanner (MPS)という記事をFacebookで公開しています。 かなり長い記事なので、ここではそのポイントをまとめて解説してみました。詳細はぜひ原文をあたってみてください。 MPSのおもな3つの機能 Facebookで稼働しているMySQLは、つねに1つのマスターとそこからレプリケーションされた複数のスレーブによるレプリカセットを構成しています。このレプリカセットの構造を維持し続けることで、可用性と
ニコニコニュースでも使われている全文検索パーサプラグイン「MySQL-ftppc」のMySQL-5.6対応版を作りました - Y-Ken Studio
MySQL-ftppc (MySQL full-text parser plugin collection) という、全文検索パーサプラグインはご存じでしょうか。 これはMySQL標準の Full Text Parser を置き換えるもので、hiroaki-kawai氏によってこの世に生まれました。 ストレージはMyISAMを利用しますので、コンパクトなソースコードが特徴です。 パフォーマンスとしては400万行、インデックスファイル.MYIのサイズが2GBを対象の検索で0.8秒程と、決して速くは無いので、100万行くらいまでのデータ向きです。 Tritonn (MySQL-5.0 + Senna)を利用しており、InnoDBの性能向上を主な目的としてMySQL-5.5や5.6への移行を望んでいるが、全文検索の扱いに困っている方 にオススメです。 ニコニコニュースなどで採用されているという実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今から備えるMySQL最新バージョン5.7
GitHub - mroonga/homebrew-mroonga: The homebrew formula for Mroonga.
