バッファプールは、InnoDB がアクセス時にテーブルおよびインデックスデータをキャッシュするメインメモリー内の領域です。 バッファープールを使用すると、頻繁に使用されるデータをメモリーから直接処理できるため、処理速度が向上します。 専用サーバーでは、多くの場合、最大 80% の物理メモリーがバッファプールに割り当てられます。 大容量読み取り操作の効率を高めるため、バッファープールは複数行を保持できるページに分割されます。 キャッシュ管理を効率化するために、バッファプールはページのリンクリストとして実装されます。使用頻度が低いデータは、LRU アルゴリズムのバリエーションを使用してキャッシュから削除されます。 バッファプールを利用して頻繁にアクセスされるデータをメモリーに保持する方法を理解することは、MySQL チューニングの重要な側面です。 バッファプールは、最低使用頻度 (LRU) ア
EXPLAINステートメントとは EXPLAINは、SQLの実行計画に関する情報を取得するためのステートメントです。実行計画とは「どのインデックスを使って（あるいはインデックスを使わずにテーブルスキャンで）クエリーを処理するか」をMySQLが判断した結果のことです。「インデックスはちゃんと使われているだろうか」「インデックスでどこまでクエリーを効率的に処理できているだろうか」という疑問が湧いた時には、「とりあえずEXPLAINで」となりますよね。 EXPLAINのマニュアルはこちらに、EXPLAIN の出力結果のカラムの意味についてはこちらに記載があります。 EXPLAINの何を見るか たとえば、次のような重いクエリーがあったとしましょう。 mysql> SELECT COUNT(some_column) FROM some_table WHERE some_column = xxx; +
SQL-92 以前では、選択リスト、HAVING 条件または ORDER BY リストが GROUP BY 句で指定されていない非集計カラムを参照するクエリーは許可されません。 たとえば、このクエリーは、選択リストの非集計 name カラムが GROUP BY に表示されないため、標準 SQL-92 では無効です: SELECT o.custid, c.name, MAX(o.payment) FROM orders AS o, customers AS c WHERE o.custid = c.custid GROUP BY o.custid; クエリーを SQL-92 で有効にするには、選択リストから name カラムを省略するか、GROUP BY 句で名前を指定する必要があります。 SQL:1999 以降では、GROUP BY カラムに機能的に依存している場合、オプション機能 T30
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が返ってくるまで待つ
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
How to Set Up Asynchronous Replication from Galera Cluster to Standalone MySQL server with GTID Hybrid replication, i.e. combining Galera and asynchronous MySQL replication in the same setup, became much easier since GTID got introduced in MySQL 5.6. Although it was fairly straightforward to replicate from a standalone MySQL server to a Galera Cluster, doing it the other way round (Galera → standa
MySQL 5.6からの機能であるGTIDを、Facebookの環境に適用した際の流れと主な不具合、そしてそれらの修正点について、Facebookのエンジニアによるまとめ。 by Evan Elias and Santosh Praneeth Banda Global Transaction ID (GTID)は、MySQL 5.6の新機能の中でも最も使わずにはいられない機能の一つだ。このおかげで、フェイルオーバやポイントインタイムリカバリ、階層を持ったレプリケーションなどに非常に有益だし、クラッシュセーフなマルチスレッドレプリケーションの必須条件にもなっている。この数ヶ月で、我々はFacebookの全ての本番用MySQLインスタンスで、GTIDを有効にした。その中で、この機能の適用方法や操作について、たくさんの知見が得られた。たくさんのサーバサイドの修正事項については、WebScaleS
(最終更新日: 2017/9/25) はじめに production 環境で MySQL 5.6 動かすためのパラメータ設計についてまとめました。この記事がカバーする内容は次のとおりです。 パラメータを設定するスクリプト。 各パラメータにおける変更するかどうかの判断基準。 想定されるメモリの消費サイズを算出してパラメータが妥当かどうか確認する方法。 サービスの状況に応じててきぎ読みかえてください。 【結論】パラメータグループ作成・パラメータ設定のスクリプト 結論として、パラメータグループを作成し、パラメータを設定する aws-cli のスクリプトを置きます。Amazon AWS の Web Console から設定することもできます。 #!/bin/sh # == パラメータグループ作成 aws rds create-db-parameter-group --db-parameter-gr
以前に作って、プロダクションでもいくつかのサービスに導入している MHA::AWS ですが、failover 方法を ENI 付け替えの他に VPC Route Table の書き換えもサポートしました。 ENI付け替えでは同一 Availability Zone 内での failover しかできませんが、VPC Route Table の書き換えによる方法では Multi-AZ 環境での failover も可能になります。 CPANにも上げましたので、 cpanm MHA::AWS でインストール可能です。 MHA::AWS - A support script for "MySQL Master HA" running on AWS - metacpan.org fujiwara/MHA-AWS · GitHub 以前の紹介記事 → #11 MySQL Master HA を AW
MySQL Casual Talks vol.5 メモ 2013-10-26 MySQL Casual Talks vol. 5に行ってきたので、自分なりのメモと資料へのリンク。 途中、アラートが鳴り始めて確認してたりしてメモが適当なところがあるが仕方なしｗ かなりのスピードでじゃんじゃんプレゼンが進んで行ったが、どれも面白い・役立つ内容ばかりで、楽しいひと時でした。発表者の皆様、会場の提供や調整などしてくださった@myfinderさんはじめとする皆様、ありがとうございました。自分の隣でビール缶を次々と「カシュッ」と空けていた@oranieさんのような余裕を持ちつつ、次回は自分も何かネタを提供できるといいなあ。 @yuryuさん GTIDを使い始めてやめた話 GTID - 全てのトランザクションを一意に識別、一貫性保証 マスタを切り替えると、マスタのUUIDが変わるのでGTIDが2個になる
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！
MySQL 5.1.38からMySQL本体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ！」もしくは「検証してるよ！」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ？！という人が多いんではないかと思うのだが、実際はどうなのだろう？現在はRC版（リリース候補版）という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将
こんにちは。リコーの井上です。今回から私もこのブログを書かせていただくことになりました。よろしくお願いします。 今回はMySQL Proxyについて書きたいと思います。MySQLを利用していると、WebアプリケーションなどのMySQLクライアントからサーバに送られるクエリを解析したい場合があります。あるいは、複数のMySQLサーバに処理を振り分けたいということがあります。 MySQL Proxyはその名の通り、MySQLクライアントとMySQLサーバの間に入って、接続やクエリで取り交わされるデータを参照・加工して、いろいろと役立つことをさせようというものです。動作内容は軽量スクリプト言語Luaにより柔軟に記述できますが、機能的制限もあります。 このエントリではMySQL Proxyとはどういうものか、どういうことができそうなのか、できないのかということを感じ取っていただければと思っています
初めまして、リコーの濱田です。このたび私も本ブログを担当することになりました。今後ともよろしくお願いいたします。 本エントリではデータベースに関する技術トピックとして、MySQL 5.1 から導入された機能であるパーティショニングについて書こうと思います。少し長くなりそうなので、「基本知識編」「性能検証編」の2回に分けて書くことにします。 今回は「基本知識編」として、パーティショニングの概要と基本的な使い方について紹介します。 パーティショニングの概要 パーティショニングとは、事前に設定されたルールに従ってデータをパーティションと呼ばれる部分的なテーブルに分割する仕組みです。 データ挿入時には、設定ルールに従ってデータが該当するパーティションに自動的に振り分けられます。データ参照時には、オプティマイザがクエリから必要なパーティションを判断し、該当するパーティションのみにアクセスします。これ
ふぁぼったーでMySQLプラグインを使いたくなったので、MySQLを5.0から5.1にアップデートしました。以下メモ。 (作業のログをWebに残していかないとダメだなーと最近思ったので練習をかねて。こういうエントリーは別途はてなグループで起こした方がいい気がするな。) 環境 CentOS 5 yumで入れたMySQL 5.0.45 参考資料 http://dev.mysql.com/doc/refman/5.1/ja/linux-rpm.html http://dev.mysql.com/doc/refman/5.1/ja/upgrade.html http://dev.mysql.com/doc/refman/5.1/ja/upgrading-from-5-0.html WEB+DB PRESS Vol.45 作者: 荒木稔,能登信晴,Zev Blut,ミック,nanto_vi,武者晶紀
mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char
バックアップするのが面倒なMySQLデータベースを自動的にバックアップできるようになるスクリプトです。 いくつものデータベースを一括でバックアップできます。1つのファイルとしてまとめてバックアップすることもできるし、各データベースごとに分けてバックアップすることもできます。バックアップファイルはgzipかbzip2で圧縮されているのでディスク容量も食いません。リモートのMySQLを中央のMySQLにバックアップしたり、バックアップのログをメールで送ることも可能。バックアップしたファイル自体をメールで送ることもできます。バックアップはcronを使う以外に手動で行うことも可能なので、cronがなくてもバックアップはできます。 ダウンロードと詳細は以下の通り。 Automatic MySQL Backup SourceForge.net: AutoMySQLBackup 最小限の設定ですぐに使う
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
From: zen kishimoto <zen kishimoto <zen@xxxxxxxxxx>> Date: Sat, 03 Sep 2005 09:24:15 -0700 Subject: [mysql 12071] 階層化されたデータをMySQLで扱う （Managing Hierarchical Data in MySQL） http://dev.mysql.com/tech-resources/articles/hierarchical-data.html （図はこのサイトを参照のこと） Mike Hillyer著 初めに 多くのユーザーは一回くらいはSQLデータベース内で、階層化したデータを 扱ったことがあると思います。そのときはリレーショナル データベースは階層化したデータ用に開発されなかったと考えたと思います。 リレーショナルデータベースのテーブルは階層化されておらず
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
