重いALTER TABLEの実行中に進捗状況を確認する方法 - CyberAgent SRG #ca_srg
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
こちらは NewsPicksアドベントカレンダーの9日目の記事です。 はじめに こんにちは。NewsPicks エンジニアの鶴房です。 フロントエンドの刷新プロジェクトにおいて、主にインフラとバックエンドを担当しています。 今回は私が以前起こしてしまったサービス全停止の障害の原因と、その再発防止策に関して記載します。 尚、弊社ではRDBMSとしてMySQLを利用しているので、この記事はMySQLに関する内容になります。 障害事象 今年の夏頃、約30分の間、NewsPicksのほぼ全てのサービスが停止してしまいました。 ユーザーは、その間、ログインも、記事を読むことも、記事にコメントすることもできない状態でした。 アプリを開くと、エラーメッセージが表示されるだけの状態で、障害の解消までずっとその状態が続いていました。 障害の直接原因 障害の直接の引き金になったのは、タイトルにある通りALTE
SnowflakeのALTER TABLEで100万溶かした顔になった - CARTA TECH BLOG
株式会社CARTA MARKETING FIRMでDSP(Demand-Side Platform)の開発をしている機械学習エンジニアのmikanfactoryです。特にMLOpsを担当しています。 背景 当社のDSPでは、配信ログを用いた機械学習モデルによる配信最適化を行っています。データパイプラインはSnowflake+dbtで構築し、Prefectを使用して機械学習モデルの構築・デプロイを実施しています。 サービスの成長に伴い、データパイプラインのコストは徐々に上昇傾向にありました。特に12月中旬には大幅なコスト増加が発生し、さらに年末年始の繁忙期を控えていたため、早急なコスト対策が必要となりました。 データパイプライン 図のような構成となっていました（※わかりやすくするために一部加工してあります）。 改善方針 影響範囲を最小限に抑えるため、上流（テーブルA、B）ではなく下流のテーブ
MySQL 8.0 vs 外部キー制約 vs ALTER TABLEでメタデータロック待ちになったら疑うこと
TL;DR MySQL 8.0(細かくは8.0.4っぽい)とそれ以降は「外部キー制約を持っているテーブルにSELECTするとそのテーブルの親テーブルにもメタデータロック(MDL)を置くようになった」 MDLであるがゆえに foreign_key_checks をOFFにしようが 無効化はできない MySQL :: WL#6049: Meta-data locking for FOREIGN KEY tables WL#6049 “Meta-data locking for FOREIGN KEY tables” and WL#11059 · mysql/mysql-server@6626f76 これ以降にもいくつかコミットが続いている 論より証拠。 サンプルスキーマはこんなかんじ。 CREATE TABLE `item` ( `item_id` int NOT NULL, `registe
MySQLの ALTER TABLE ステートメントの実行形式について学んだメモ✍ - 継続は力なり
タダです. DB マイグレーションなどで ALTER TABLE ステートメントを実行する機会は多いと思いますが,自分は ALGORITHM 指定した実行形式を意識して使ったことがこれまでありませんでした.今回実行形式に触れる機会があったので学んだメモをまとめます. ALTER TABLE ステートメントにおける実行形式 MySQL において ALTER TABLE ステートメントの実行形式は3つあります. COPY INPLACE INSTANT COPY COPY は新しいテーブル定義で一時テーブルを作成し,既存データをコピーして入れ替えます.ALTER TABLE ステートメント実行中テーブルをロックするため,実行中は書き込みがブロックされます.大規模テーブルへのロックがかかると,サービス利用に影響も出てしまうのでメンテナンスも必要になります.利用するケースとして主キーの削除やデータ
はじめに こんにちは。ビジネスチャットサービス Typetalkを開発・運用している吉田です。先日PostgreSQLでのALTER文をいかに無停止で安全に行うかという記事を公開しました。その中で以下のようにNULLを不許可にしたカラムを追加する際の注意点について述べていました。（参照 NULLを不許可にしたカラムを追加する） 新しいカラムを追加する際、NULLを不許可にしたいことがあります。その場合よく使われるのがALTER TABLE構文で同時に追加できるNOT NULL制約です。このNOT NULL制約をつけるためには、既存レコードにデフォルト値を設定する必要があるため、DEFAULT構文を同時に使用することになります。 ALTER TABLE todo ADD COLUMN completed BOOLEAN NOT NULL DEFAULT false; この構文は自動的に既存の
今回はALTER TABLEステートメント実行時の注意点について紹介します。 MySQLを運用していると、サービスの仕様変更や新機能のために既存のテーブルに対してテーブル定義を変更することが多いと思います。その際によく起こる問題や注意点に説明します。 ALTER TABLEステートメント まずは、簡単にALTER TABLE ステートメントについて紹介します。テーブル定義を変更するにはALTER TABLEステートメントを利用します。MySQL 5.6以降からInnoDBのテーブルにおいて、オンラインDDLが可能になっています。本連載においても第30回 InnoDBオンラインDDLについてにて紹介しています。 オンラインDDLでは、DDL実行に最小限の時間のロックを取得することで、そのDDLと並列で実行されるDMLの待機も最小限になります。そのため、サービス無停止でALTER TABLEス
MySQLでカラム追加などのalter table中にクエリがブロックされるかなどについてのメモ - だいたいよくわからないブログ
これは何 MySQLのカラム追加などのDDL, alter table時にそれぞれの操作がどれくらい危険なのか、負荷は？といった情報の見方を毎回忘れるのでメモしたもの まとめ 公式document に詳細な表があるのでそれを見ると良い。 ただし必ずしもその表通りになるわけではないため表の下に記載されている注意書きをよく読む必要がある。 例えば varcharのサイズ変更 = Extending VARCHAR column size は表内では INPLACE=yes と記載されているが length を 255 から 256 に拡張する場合は ALGORITHM=COPY しか利用できないといった制限が記載されているので見落とさないようにすべき。（MySQL8.0 公式doc） 余談だが上記の事象については MySQLでのVARCHARサイズ変更を行うALTER TABLEについて -
運用をしているとダウンタイムかありかに関わらず、alter tableにどれくらいの時間がかかるのか作業前に把握したいことはよくあります。 各種statusを見ることで一定時間でどれくらいの行を書き換えるかを把握することはでき、作業を始めてからであれば、あとどれくらい掛かりそうかは見積もれますが、alter tableの話が出た瞬間にどれくらい掛かりそうかの目処はつけたいです。 今回はalter時に実行されるDMLがなく、テーブルに断片化もないという理想的な環境で、各種Alter操作にどれくらいの時間がかかるのかを実験してみました。 環境やconfigの詳細はあえて書いていませんが、どちらにしろ実際には様々な要因が絡むので、このくらいの情報があれば充分かと思います。 概要 alter tableにかかる時間を計測 on/off memoryでALTER TABLEにどれくらい時間がかわるか
MySQLの初期のALTER TABLEの実装は非常にシンプルな実装でした。 新しいテーブル定義で(内部的に)一時テーブルを作成し、そこに既存のデータをコピーして、コピーが終わったら入れ替えます。コピー中は更新をブロックします。 MySQL v5.6 で オンラインDDL がサポートされ、更新がブロックされなくなりました。 また、v8.0 では、INSTANT ADD COLUMN が登場し、カラム追加が一瞬できるようになりました。 このように MySQL の DDLは進化を続けてきたのですが、全ての ALTER TABLE で新機能が使えるわけではありません。 マニュアルには○×の記載があるのですが、早見表のようなものが欲しかったので、まとめてみました。 早見表 v5.7 のマニュアルをベースに、DDLの挙動をまとめました。v8.0でDDLまわりは大きく改善されているので、v8.0では違
アソビュー！ Advent Calendar 2024 12日B面 はじめに こんにちは。アソビューでエンジニアをやっています。小池です。 最近、MySQLのテーブルにインデックス追加 (ALTER TABLE) をしたのですが、その際にメタデータロックを発生させてしまい、一時的な障害につながりました。 今回の記事はその際の学びと再発防止案として、メタデータロックにタイムアウトを設定して安全にALTER TABLEを実行する話です。 よろしくお願いします！ ALTER TABLEとメタデータロック まず、メタデータロックについて簡単に説明し、今回起こった事象について整理していきます。 メタデータロック MySQLのメタデータロックはテーブルの中身ではなく、テーブル構造に対して行われるロックで、トランザクション内でテーブル構造の一貫性を保つために行われます。 SELECTなどのDMLは共有メ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
小さなテーブルへのALTER TABLE一撃でサービス停止。そこから学んだ惨事を繰り返さないためのルール作り - Qiita
PostgreSQL 11でALTER TABLE ... NOT NULL DEFAULTが簡単になっていた | 株式会社ヌーラボ(Nulab inc.)
第209回 MySQLのALTER TABLEステートメント実行時の注意点 | gihyo.jp
ALTER TABLEにかかる実行時間を見積もりたい - tom__bo’s Blog
MySQL ALTER TABLEとその影響まとめ - mita2 database life
MySQLでメタデータロックを考慮してALTER TABLEする - asoview! Tech Blog