大規模環境でMySQLのGTIDを適用して得られた教訓 | Yakst
MySQL 5.6からの機能であるGTIDを、Facebookの環境に適用した際の流れと主な不具合、そしてそれらの修正点について、Facebookのエンジニアによるまとめ。 by Evan Elias and Santosh Praneeth Banda Global Transaction ID (GTID)は、MySQL 5.6の新機能の中でも最も使わずにはいられない機能の一つだ。このおかげで、フェイルオーバやポイントインタイムリカバリ、階層を持ったレプリケーションなどに非常に有益だし、クラッシュセーフなマルチスレッドレプリケーションの必須条件にもなっている。この数ヶ月で、我々はFacebookの全ての本番用MySQLインスタンスで、GTIDを有効にした。その中で、この機能の適用方法や操作について、たくさんの知見が得られた。たくさんのサーバサイドの修正事項については、WebScaleS
MHAをAWSで使うための支援ツールMHA::AWSをアップデートしてCPANに上げた - 酒日記 はてな支店
以前に作って、プロダクションでもいくつかのサービスに導入している 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の障害解析方法 - Qiita
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです＞＜ 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
MySQLゆるふわ運用のためのアグレッシブ開発 ～ データを増やさないための設計と運用方針について(主にパーティション活用の話)
MySQLゆるふわ運用のためのアグレッシブ開発 ～ データを増やさないための設計と運用方針について(主にパーティション活用の話)
ConsulによるMySQLフェールオーバー - @ijin
先日(6/22/14)、6月なのにどういう分けか早めに開催されたJuly Tech Festa 2014でConsulについて発表してきた。そのユースケースの一つとしてMySQL failoverをちょっとだけ紹介したので、ここに詳しく書いておく。 MHA MySQLレプリケーションの障害時にフェールオーバーしたい場合、MHAを使うの結構ポピュラー（日本では）だと思います。MHAは最新binlogの適用、Slaveの昇格とレプリケーションの張替えまではやってくれますが、実際のフェールオーバーの部分はユーザに委ねられていて、master_ip_failover_scriptのテンプレートをカスタマイズするか独自実装する必要があり、一般的な実現方法としてはカタログデータベースの更新かVirtual IPの切替等があります。 Virtual IPだと居残りセッションの問題や切替の保証難しかったり
【メモ】MySQLでのswap発生とNUMAアーキテクチャ - FAT47の底辺インフラ議事録
DBサーバでとある日を境にswapが発生していることに気がつきました。 サーバはメモリ32GB搭載していて、そのうちの24GBをinnodb_buffer_pool_sizeに割り当てています。 他のthread毎のメモリ設定値を見てもおかしそうな点はなかったのでググってみました。 MySQL と NUMA アーキテクチャと Swap Insanity MySQL InnoDBストレージエンジンのチューニング（後編） なるほど…。 それぞれのCPUがローカルでメモリを管理しているので、 2CPU積んでいるサーバだと、AというCPUで実行されているスレッドが、BというCPUが確保しているメモリ領域にアクセスするには、AのCPUを経由しないといけないわけですね。 このメモリアクセスが不均一になる方式をNUMAアーキテクチャというみたいです。 NUMAアーキテクチャのメモリ管理が、ノードという単
Why I want to stop using range partition with timestamp column - maedamaのブログ
Partition 周りで社内で説明する事が有ったのでせっかくなのでブログをかきます。 注.) 僕自身はMySQLにさほど詳しくはないので、完全には鵜呑みにしない事をおすすめしますが 下記のようなテーブルがあったとします CREATE TABLE messages ( id int unsigned NOT NULL, user_id int unsigned NOT NULL, content varchar(255) NOT NULL DEFAULT '', created_at int unsigned NOT NULL PRIMARY KEY (id), KEY `on_user_id` (user_id) ) Engine=InnoDB DEFAULT CHARSET=utf8; データ量が多かったりして、3ヶ月以前のデータをPurgeするとか考えだすとdeleteは重いので、め
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
online-schema-changeを過信していたら痛い目をみた話 - FAT47の底辺インフラ議事録
先日記事に書いたように、無停止のALTER文実行では Percona-ToolkitのOnline-schema-changeを利用しています。 無停止でALTERできるPercona-Toolkitのonline-schema-change オンラインでのカラム追加 私が担当しているサービスでは、ALTER文実行時にレプリケーションの遅延を出来るだけ発生させたくないので、 以下の様な手順でOnline-schema-changeを実行しています。 (1) スレーブ全台でOnline-schema-changeの実行 (2) マスターでOnline-schema-changeの実行（--set-vars="sql_log_bin=0"のオプション指定） "sql_log_bin=0"オプションをつけて実行すると、binlogを出さずに実行できるので、 マスターで実行してもそのクエリはスレー
DB KPI取得のススメ - 筋トレとともに生きるDBAの雑記
まずそもそもKPIってなんやねん、と。 Key Performance Indicator 業績管理評価のための重要な指標 KPIとは【Key Performance Indicator】（重要業績評価指標） - 意味/解説/説明/定義 ： IT用語辞典 用語的な意味はこんなとこですが、ここではざっくり「DB性能評価指標」と考えてください。 うちの会社では定常的にMySQLから情報を吸いあげて、これを蓄積しつつ性能管理に役立てています。 これをDB KPI管理なんて呼んでいます。 著作権が怪しいのでソースを載せるのは控えますが、延々とshow statusの60秒間の平均を取るスクリプトをdaemontoolsで回し続けています。 取得対象はCom_[insert|delete|update|select]、Innodb_rows_% (うちはInnoDBばかりなので) あたりです。 累積
MySQL :: MySQLを選ぶ理由
MySQLを選ぶ理由 MySQL® データベースが、世界でもっとも普及しているオープンソースデータベースである理由。それは、MySQL が一貫して高性能、高信頼を提供し、しかも扱いやすいからです。MySQL は、南極大陸さえも含む、世界中の全大陸の個人 Web 開発者から世界有数の大規模組織に至るまでの幅広いユーザによって用いられ、開発時間とコストの節約を実現しながら大容量 Web サイトや基幹業務システム、パッケージソフトウェアの原動力として活躍しています。MySQL を導入する組織には、各業界のリーダとして君臨する Facebook、Google、Adobe、Alcatel Lucent、Zappos.com などが含まれます。 MySQL を用いてコスト効率に優れたデータベースソリューションを実現できるよう、事例集やホワイトペーパー、アナリストレポートなどを含む、以下の関連資料をご覧
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLのバックアップ運用について色々
ふつうのWeb開発者のためのクエリチューニング
TokuDB試してみる
Getting to know TokuDB for MySQL
株式会社TAP
https://www.usenix.org/sites/default/files/conference/protected-files/solomon_lisa12_slides.pdf
MySQLチューニング
