こちらは NewsPicksアドベントカレンダーの9日目の記事です。 はじめに こんにちは。NewsPicks エンジニアの鶴房です。 フロントエンドの刷新プロジェクトにおいて、主にインフラとバックエンドを担当しています。 今回は私が以前起こしてしまったサービス全停止の障害の原因と、その再発防止策に関して記載します。 尚、弊社ではRDBMSとしてMySQLを利用しているので、この記事はMySQLに関する内容になります。 障害事象 今年の夏頃、約30分の間、NewsPicksのほぼ全てのサービスが停止してしまいました。 ユーザーは、その間、ログインも、記事を読むことも、記事にコメントすることもできない状態でした。 アプリを開くと、エラーメッセージが表示されるだけの状態で、障害の解消までずっとその状態が続いていました。 障害の直接原因 障害の直接の引き金になったのは、タイトルにある通りALTE
こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし
はじめに こんにちは。calloc134 です。 前のハッカソンイベントで、UUID をプライマリキーに利用するかどうかの議論がありました。 結果的にはあまりパフォーマンス要件の高くないアプリケーションであったため、プライマリキーとして UUID を採用することにしたのですが、イベント終了後に気になったため、調査を行いました。 今回は、この調査の結果を元に、MySQL と PostgreSQL におけるインデックスの内部構造の違いと、UUID をプライマリキーにする際の問題についてまとめてみたいと思います。 インデックスの概要 インデックスとは インデックスとは、データベースのテーブルに対して、アクセスを高速に行うための指標となる構造のことです。 インデックスとは日本語で索引ですが、まさに辞書の索引のように、アクセスにおいての手助けをしてくれます。 より具体的に解説すると、データベースにお
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
Linux女子部 「Fedora最新技術情報＆Systemd勉強会」 http://connpass.com/event/3859/ で使用した資料です。 変更履歴 2013/11/04 ver1.0 初版 2013/11/05 ver1.1 誤植修正、少し追記 2013/11/06 ver1.2 daemon-reload,mask,テンプレート機能を追記 2013/11/12 ver1.3 User/Groupオプションの説明追加 2013/11/24 ver1.4 誤植修正 2014/05/05 ver1.5 imjournalモジュールの説明追加
結果、保存できなかった😢 SET sql_mode = STRICT_ALL_TABLES; CREATE TABLE time_leap ( dt datetime, ts timestamp ) ENGINE=InnoDB; INSERT INTO time_leap VALUES ('2012-06-30 23:59:59', '2012-06-30 23:59:59'); -- Query OK, 1 row affected (0.02 sec) INSERT INTO time_leap VALUES ('2012-06-30 23:59:60', '2012-06-30 23:59:60'); -- ERROR 1292 (22007): Incorrect datetime value: '2012-06-30 23:59:60' for column 'dt' at r
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
