Rails 3 系+MySQL を利用しているサービス向けに 1. どのようにボトルネックを探すのか 2. どのような設計を行えばいいのか 3. Rails上でどのようなコードを書けばいいのか の3点に絞ってこのプレゼンをみてチューニングを行えるように資料作成を行いましたRead less
ちょっとした小ネタです。RDS(MySQL)に於いて、『utf8mb4』に対応した環境が作成出来るか/対応しているかという件で確認する機会がありましたので、当エントリに備忘録的として記しておきます。 目次 『utf8mb4』とは RDS(MySQL)環境の用意 『utf8mb4』に対応したパラメータグループを作成・適用 『utf8mb4』関連パラメータグループ適用後の内容確認 『utf8mb4』とは この『utf8mb4』というもの、文字コードの一種で、UTF8で4バイト文字を扱う事が出来るものらしいです。 MySQLで4バイトのUTF-8文字を扱ってみる - HHeLiBeXの日記 正道編 また、それぞれのバージョンで扱う事が出来るCharacter Setの一覧も以下にメモしておきます。 MySQL :: MySQL 5.1 Reference Manual :: 10.1.13 Ch
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
オンラインストレージサービスのDropboxが、米国時間1月10日の午後から約2日間にわたって障害を引き起こしていました。直接の原因は、OSをバージョンアップするために実行したメンテナンス用スクリプトにバグがあったことです。 障害の状況を時系列で追いつつ、原因についての報告を見てみましょう。 約48時間続いた復旧作業 障害の状況報告については、Dropbox Tech Blogの「Dropbox Status Update」でまとめられています。ポイントごとに引用し、訳しました。 障害発生が認識されたのは、米太平洋時間の午後6時40分です。後になって分かるのですが、この日の5時半に障害の原因となったメンテナンスが始まっています。それから1時間後にDropboxのダウンが発覚します。 1/10 at 6:40pm PT: We are aware that the Dropbox site
テーブル設計においてカラムのデータ型を正しく決めることには、どのような利点があるのかについて。単純に扱う値と同じ型を選ぶべきであるというだけではなく、なぜそうあるべきかについて、内部的な効率の面から解説する。 パフォーマンスに関する話の中で、カラムに値を保存するのに正しいデータ型を使うことの重要性を説いているのを聞くことがよくある。例えば、数値はINTやBIGINTで表現し、IPアドレスにはINT UNSIGNEDを使い、VARCHAR(255)の代わりにVARCHAR(60)を使うといったことだ。 このアドバイスは正しい。しかし、今日はもう少し詳細の説明を試みてみようと思う。 理由 この最適化が正しいと思う3つの理由は以下の通りだ。 文字列として数値データを扱うことは、文字コードや照合処理のCPUオーバーヘッドが余計に必要になってしまう。例えば、'Montréal' = 'Montrea
MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe
ホーム 技術ブログ PHPMatsuri2013で発表した資料を公開しました「ソーシャルゲーム案件におけるDB分割のPHP実装~とにかく分割ですよ。10回じゃ足りない。20回くらい分割。~」 PHPMatsuri2013で発表した資料を公開しました「ソーシャルゲーム案件におけるDB分割のPHP実装~とにかく分割ですよ。10回じゃ足りない。20回くらい分割。~」 記事を書くのは初めてになります。sasakiです。 2013年7月14日から15日にかけて、PHP Matsuri 2013が開催されました。 今回は北海道開催という事で弊社もスポンサーとなり、社員の何名かはスタッフとして開催に協力しました。 また、スポンサー枠でセッション時間を一コマ頂き 「ソーシャルゲーム案件におけるDB分割のPHP実装 ~とにかく分割ですよ。10回じゃ足りない。20回くらい分割。~」 と題した発表を行いましたの
[:W560] Log集計用DB設計 考える問題 Document無しのAgile開発をガチで推奨したい@yutakikuchi_です。【進撃の巨大データ】の第2回目として巨大アクセスLog集計用DBの設計について勉強した内容についてメモしたいと思います。DB周りはそこまで詳しく無いので詳しい皆様からの突っ込み大歓迎でございます。また図々しいですが知恵をください(笑)。 今日の主目的は下の2要件を叶えるためのDB設計を考える事です。特に問題になるのがRealTimeの話でTableにLogDataを書き込む処理と集計のSQLをどのように組み立てるか、それ以外にもSystemPerformanceとArchitectureにも関わってきます。 リアルタイムで大量データを集計したい 定期処理で大量データを集計したい 使うもの Fluentd : Fluentd: Open Source Log
追記:記事の文中で5.6のsql_modeデフォルト値について若干実際の挙動と異なる表記をしていました。rpmでinstallすると/usr/my.cnfというのがひょっこりいて、この中に [mysqld] sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES という記述があり、これを/etc/my.cnfと合わせて設定している様です。で、デフォルト値については5.6.6以降はデフォルト値が「The default SQL mode in MySQL 5.6.6 and later is NO_ENGINE_SUBSTITUTION;」でそれ以前のデフォルト値は「MySQL 5.6.5 and earlier, it was empty (no modes set)」となっているようですね。 詳しくは http://yoku0825.blo
諸事情で remi リポジトリから入れていた MySQL 5.5 を CentOS リポジトリの 5.1 に戻しました。 remi から MySQL をインストールする手順は下記の 方法2 標準リポジトリの優先度を remi より高く で行なっている前提です。 CentOS6 で remi から php や mysql をインストールするための yum の設定 #CentOS #PHP #MySQL - Qiita 試行錯誤の跡 まずは yum リポジトリの設定を変更します。 php と mysql だけ CentOS の標準レポから除外していたので、php だけ除外するように修正します。 /etc/yum.repos.d/CentOS-Base.repo - exclude=php* mysql* + exclude=php* そしておもむろにダウングレード。 # yum downgra
CentOS 6.4にMySQLをrpmで入れることにする。MySQLは、5.6系はまだ初物すぎるので5.5系を入れようか。 ダウンロード まずはOSデフォルトのyumリポジトリから入れようかと、バージョンを確認。 [ozuma@paracent ~]$ yum info mysql.x86_64 Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: ftp.iij.ad.jp * extras: ftp.iij.ad.jp * updates: ftp.iij.ad.jp Available Packages Name : mysql Arch : x86_64 Version : 5.1.67 Release : 1.el6_3 Size : 886 k Repo : updat
斎藤です。こんにちは。 今日は、MySQLにてレプリケーション構成において、マスタサーバのフェイルオーバーを司るmysql-master-ha(以下、MHA)を用いる際、マスタサーバ接続先の切り替えにHAProxyを使ってみようというお話です。 ※MHAは0.53.0(公式パッケージ)、MySQLは5.5.25a(Oracle公式パッケージ)、HAProxyは1.4.22(CentOS6標準パッケージ)、OSはCentOS 6.3 x86_64を用いました。 ※MHAによる冗長化およびHAProxyによるMySQLの負荷分散の設定を経験された事がある前提で記述します。 本記事では、次の流れで話題を展開します。 フェイルオーバー時の接続先切り替え方法 構成(参考) なぜHAProxyなのか 切り替え方 2台構成の問題点 その他 コツ 設定(参考) 主にMHA+HAProxyによるフェイルオー
こんにちは、テクニカルグループの柳瀬です。 アプリケーションサーバからMySQLへの参照を負荷分散する場合、HAProxyを使うことがあります。 AWS上で構築している場合はリードレプリカへの参照を負荷分散させたいというご要望を受けた時ですね。 HAProxyは負荷分散対象に監視を設定し、ダウンと判断したものは分散対象から除外してくれるのでとても便利です。 しかし、MySQLへTCPで監視を設定しているとMySQL側が監視用のパケットを不正と判断して、リクエストを受け付けなくなってしまいます。 max_connect_errorsを大きい値にするという対応もありますが、HAProxyの監視設定で使用するmysql-checkにユーザーオプションを使用すれば不正なパケットとはなりません。 検証環境構成Amazon LinuxHAProxy 1.4.22RDS(Multi AZ)RDSリードレ
MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を 発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。 さらに、RESET SLAVE ALL;というクエリもサポートされたようです。 どういう事なのでしょう? 調べてみました。 ドキュメントにさらっと何か書いてある In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. Thi
mysqlvizはMySQL/SQLiteの構造を可視化するライブラリです。 DBを使ったシステムを構築していると必要になるのがER図ではないでしょうか。そんなER図を実際のデータベースのダンプファイルをベースに描き出すのがmysqlvizです。 ヘルプです。 まずdotファイルを生成します。 さらにdotファイルをpngに変換して得られた結果です。 mysqlvizはMySQLとSQLiteに対応しています。MySQLの場合はダンプファイル、SQLiteの場合は実際のデータベースファイルを読み込んでdotファイルを出力します。後はGraphvizを使ってPNG画像に変換する仕組みになっています。 mysqlvizはPHP製、GPL v3のオープンソース・ソフトウェアです。 MOONGIFTはこう見る mysqlvizの面白いところはMySQLについてはダンプファイルを使っているということ
PHP 5.5 で mysql 拡張モジュールが非推奨になり、E_DEPRECATED エラーが表示されるようになりました。将来の PHP のバージョンで削除されます。 mysql 拡張モジュールに依存する CMS を使ってサイトを運用している場合、将来、運用サーバーに導入されている PHP のバージョンの切り替えに備えて、 mysqli もしくは PDO に対応した CMS のバージョンへのアップグレードするか、別の CMS やウェブサービスに切り替える必要があります。 多くの PHP 製の CMS が共有ホスティングにインストールされており、共有ホスティングは比較的古い PHP のバージョンのサポートを続ける傾向にありますが、古い PHP のバージョンを使い続ける場合、PHP のバグやセキュリティの未対応、より新しい PHP のバージョンを最小バージョンとするライブラリや CMS を導
目黒川の桜きれいですね〜(*^^*)…なーんてガラじゃないことを言いたくなるくらい良い咲きっぷりでしたよ、エエ。で、来週末、花見に行くんだけど、まだ散らないでほしいっすねー。 えーっと、久しぶりにMySQLの記事。binlogを使ったリストア手法について。ネットを漁るとMySQLの運用に関する記事は多くヒットするんだけど、障害からのデータリカバリ、特にロールフォワードを扱った記事が思ったより多くない。おれは運が良いのか悪いのかMySQLのデータリカバリをしなければならないような局面に何度か直面しているので、手順について書いてみようかな、と。ここではMySQL〜5.5を対象にしている。直近での最新のメジャーバージョンはMySQL5.6なんだけど、おれはまだ5.6について大して知らない。5.6ならもっとイケてるやりかたがあるかもしれない。あったらいいな。 0. 環境 次のような環境を前提として
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く