「MySQLのフェイルオーバーテストをする」と聞いてぼんやり思ったこと
TL;DR 負荷をかけながらフェイルオーバーテストをするなら、負荷クライアント側で「どの書き込みが成功したのか」のログは必ず取っておく でないと、フェイルオーバー起因でデータロストが発生するのかしないのかのチェックができない フェイルオーバーシナリオ スイッチオーバー(手動での切り替え)を含めてざっと思いつくのはこれくらい。 スイッチオーバー mysqldの正常終了 mysqldの異常終了、特に、mysqld_safeやsystemdがmysqldを再起動させてしまう環境 mysqldのハングアップ カーネルパニック ファイルシステムのハングアップ 電プチ スイッチオーバー たぶんHAソリューションを作る時にちゃんとテストするからこれはそんなに問題にならない気がするけれど、(レプリケーションベースのソリューションの場合)「レプリケーション遅延が起こってる時のスイッチオーバー」で何が起こるか
MVCCとInnoDBでの実装について - shallowな暮らし
こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
Dropbox のスケールとか
Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 (comment) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、2006 年当時はオンラインストレージサービスがいっぱいあったようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか？" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ！当時、プ
クエリの改善に。MySQLのSlow Query Logを可視化する·MySQL slow-query-log Visualizer MOONGIFT
MySQL slow-query-log VisualizerはMySQLの時間のかかるクエリをWeb上で閲覧するソフトウェアです。 MySQLには実行時間の遅いクエリをログファイルに書き出す機能があります。単純にテキストに吐かれるだけなので分析に時間がかかってしまうのではないでしょうか。そこで使ってみたいのがWebブラウザベースの解析ソフトウェアMySQL slow-query-log Visualizerです。 サンプルです。データ量が多くないとあまり面白くないですね。 公式サイトより。曜日ごとに発生回数をグラフ化しています。 クエリログファイルをWebブラウザの画面にドロップするだけで解析処理が行われます。その結果はグラフに描かれる仕組みです。また、クエリは一覧で表示され、任意の文字でフィルタリングすることもできます。曜日と時間によって分析されるので対応すべきポイントが分かりやすくな
MySQL InnoDBストレージエンジンのチューニング（後編）
チューニングの基礎 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。 バッファプール 最も基本となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。 innodb_buffer_pool=32G ここで一つ注意がある。innodb_buffer_pool_sizeはバッファプー
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLを割と一人で300台管理する技術
実例Javaトラブルシューティング！ 〜稼働中のシステムを立て直した半年間の軌跡
Mysql toranomaki
http://www.2ch-search.net/blog/3