MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary
この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの
MySQLのタイムアウトエラー（#1205 - Lock wait timeout exceeded）の確認及び対処 | 古松
MySQLエラー：#1205 - Lock wait timeout exceeded; try restarting transaction mysql MySQLのあるテーブルにデータ移行（insert）時にエラーが発生しました #1205 - Lock wait timeout exceeded; try restarting transaction mysql エラー後に「try restarting transaction」で、MySQLがデータ追加プロセスを再起動したようです データ移行SQL文（非常に単純なテーブル間のデータ移動） insert into drills_ch_sentence_temp select * from drills_ch_sentence 原因：不明（おそらくデータ量が多い） はっきりした理由は分かりません おそらくデータ量が多い、テーブル作成時に
transactionの途中でトランザクションが切れてしまった時にそのトランザクションを殺す方法 - Garbage in, gospel out
起こったこと transactionモードで作業途中、セッションが切れた。 そのとき特定tableにinsertをしたがcommitしていない状態だった。 後ほど再度そのtableをselectしたが、当然commitしていないのでデータがなかった。 しかしinsertしようとすると、 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction というエラーが表示され失敗した。 原因 transactionがロックを取得したまま放置状態になっていたために発生した。 対処 基本方針は show processlist; と show innodb status; の結果を見比べてそれっぽいthread見つけて kill [thread id] する。 show processlist; してみると、今回
トランザクションを強制的に終了させる - HHeLiBeXの日記 正道編
前置き MySQL 5.1で、InnoDBなデータベースを使って何かを開発している最中には、トランザクションがコミット(またはロールバック)される前にプログラム側の処理が(Fatal errorなどで)異常終了したりして、トランザクションがロックを取得したまま放置状態になってしまうことがよくあるらしい(謎)。 そんな時、MySQLのコマンドラインから更新クエリを発行すると、しばらく後に次のようなエラーが返ってくることがある。 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 一応参考までに書いておくと、このエラーが返ってくるまでの時間は、次のコマンドで知ることができる。 mysql> show global variables like 'innodb_lock_wait_timeout';
Mysqlでログ系テーブルを運用するときやっておきたいこと - 主夫ときどきプログラマ
SNSやソーシャルゲーム、アドネットワークなどのシステムではいろいろなログ情報をDBに保存することもあると思います。 そのさい、日々増えつづけるデータやパフォーマンスをどの様にさばいていくかが重要になってきます。 今回はログ系のデータをMysqlでどのように運用していくか、をテーマにいくつかのノウハウをまとめました。 ログ系テーブルの特徴 ログ系のデータとは、つまり何かのアクションの履歴データのことです。 一般的にはこのような形になるかと思います。 CREATE TABLE `t_logs` ( `id` bigint(20) unsigned NOT NULL, `user_id` int(10) unsigned NOT NULL DEFAULT '0', `event_id` int(10) unsigned NOT NULL DEFAULT '0', `created` datet
[MySQL] テーブルをコピーする - ねこの足跡R
MySQLでテーブルをコピーします。 以下の2つのパターンのそれぞれの特徴についてメモします。 パターン1 CREATE TABLE newtable LIKE oldtable; INSERT INTO newtable SELECT * FROM oldtable; パターン2 CREATE TABLE newtable SELECT * FROM oldtable; テーブルをコピー CREATE TABLE ... LIKE 構文 構文 試してみる CREATE TABLE ... SELECT 構文 構文 試してみる 参考ページ テーブルをコピー MySQLでは大きく2つの方法があり、それぞれ特徴があります。 １つずつ試してみたいと思います。 今回はコピー元のテーブルとして以下のテーブルを用意しました。 /*-- コピー元のテーブル --*/ CREATE TABLE foo(
![[MySQL] テーブルをコピーする - ねこの足跡R](https://cdn-ak-scissors.b.st-hatena.com/image/square/9f4c59e5594da00c04c6d246a7b99246fec4de39/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F820878482973262145%2F6801883189061407663%2F1701446110)
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
MySQLで全テーブルのレコード数を一覧表示する - Qiita
mysql> select table_name, table_rows from information_schema.TABLES where table_schema = 'zabbix'; +----------------------------+------------+ | table_name | table_rows | +----------------------------+------------+ | acknowledges | 15 | | actions | 33 | | alerts | 4104 | | application_discovery | 0 | | application_prototype | 0 | | application_template | 1109 | | applications | 1669 | | auditlog |
MySQL :: MySQL 8.0 リファレンスマニュアル :: B.3.2.8 パケットが大きすぎます
通信パケットは、MySQL サーバーに送信される単一の SQL ステートメント、クライアントに送信される単一行、またはソースレプリケーションサーバーからレプリカに送信されるバイナリログイベントです。 MySQL 8.0 Server およびクライアント間で転送可能なパケットの最大サイズは 1G バイトです。 MySQL クライアントまたは mysqld サーバーが max_allowed_packet バイトより大きいパケットを受け取ると、ER_NET_PACKET_TOO_LARGE エラーが発行され、接続が失われます。 一部のクライアントでは、パケットが大きすぎる場合、「クエリー中に MySQL サーバーへの接続が失われました」というエラーを受け取ることもあります。 クライアントとサーバーの両方にそれぞれ max_allowed_packet 変数があるため、大きなパケットを処理する場
【Ruby on Rails】重複しているレコードを取得する【MySQL】 - きゃまなかのブログ
概要 はじめに 重複しているレコードを取得 MySQL の場合 Ruby on Rails の場合 重複しているレコードを全て取得 MySQL の場合 Ruby on Rails の場合 おまけ 条件を満たさない重複レコードを削除する MySQL の場合 Ruby on Rails の場合 まとめ 概要 Ruby on Rails で DB から重複しているレコードを取得したい時がありました。 MySQL で重複しているレコードを取得する方法は分かるのですが、Ruby on Rails で同じ処理を書く場合、どうしたら良いのか分からなかったので調べて見ました。 MySQL で書く場合と、Ruby on Rails で書く場合の 2 パターン用意しています。 はじめに 今回利用するテーブルの中身を確認します。 ユーザ名 aaa が 3 件重複、bbb が 2 件重複、ccc が重複無しとなっ
mysqldumpでCouldn’t executeと言われた時の対策 – 塩焼きブログ
下記のようなmysqldumpコマンドを実行したところ mysqldump -h database -u hoge hoge2 -phoge3 --skip-lock-tables --default-character-set=utf8mb4 hoge4 hoge5 > ~/Downloads/hoge6.sql 下記のようなエラーが出た mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"') FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = 'hoges' AND TABLE_NAME = 'item';': Unknown table 'COLUMN_S
ActiveRecordで普通のEnum型カラムを作成する - Qiita
はじめに ActiveRecordでEnumカラムを実現しようとすると、一般的にはモデルにシンボル配列を定義して、カラム自体は数値型にする場合が多いようです。しかし、このやり方では以下の問題が発生します。 可読性が著しく落ちる ツールを利用してテーブルを閲覧しても、カラムの値が何を意味しているかわからない データベースを利用する為の情報が、アプリケーション(モデル)とデータベースに分離されてしまう データベースが、このActiveRecordを利用したアプリケーションに依存してしまう 特に、rubyを使わないアプリケーションからこのデータベースを利用する際に問題が生じる 一般に、データベースはアプリケーションより寿命が長く、また昨今では収集したデータをpythonで分析することも少なくない為、ActiveRecordにデータベースの構造を左右されたくありません。よって、意地でもEnum型の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLのデータをcsv,tsv形式でダンプする - Qiita
重複しているレコードを検索するSQL(大量データも対応) - Qiita
https://tech.kurojica.com/archives/6291/
【MySQL】外部キー制約を一時的に無効にする - Qiita
MySQLのAUTO_INCREMENTについて色々と調べてみた。 - Qiita
MySQLで外部キーの制約があるテーブルをtruncateする方法 | ハックノート
MySQL 8.0.16 でテーブルスペース・REDO ログ／UNDO ログ・システムテーブル暗号化 - Qiita
[MySQL]インデックスによるチューニング〜ログ出力、EXPLAIN、インデックス〜 - Qiita![[MySQL]インデックスによるチューニング〜ログ出力、EXPLAIN、インデックス〜 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/da8d28daab7d8e34057e298d75a0708586be3315/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCTXlTUUwlNUQlRTMlODIlQTQlRTMlODMlQjMlRTMlODMlODclRTMlODMlODMlRTMlODIlQUYlRTMlODIlQjklRTMlODElQUIlRTMlODIlODglRTMlODIlOEIlRTMlODMlODElRTMlODMlQTUlRTMlODMlQkMlRTMlODMlOEIlRTMlODMlQjMlRTMlODIlQjAlRTMlODAlOUMlRTMlODMlQUQlRTMlODIlQjAlRTUlODclQkElRTUlOEElOUIlRTMlODAlODFFWFBMQUlOJUUzJTgwJTgxJUUzJTgyJUE0JUUzJTgzJUIzJUUzJTgzJTg3JUUzJTgzJTgzJUUzJTgyJUFGJUUzJTgyJUI5JUUzJTgwJTlDJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02NzMyN2Y0M2UxZTA0ZWZkZjFkZjg4ZTIyYjljNTYxMg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc2h1bnRhcm9fdGFtdXJhJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03NTIzZDczZGI1NzYyYzBhZWM5NjZlOGE1NGE3ODU5YQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D78c0c1dac295c4a4e9ea1ab361a7e2b2)
