誰も教えてくれなかったMySQLの障害解析方法 - Qiita
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです＞＜ 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
Docker公式MySQLのDockerfileを頑張って読んで理解しようとしてみた[docker-entrypoint.sh編] | Unskilled?
Dockerfileが読みたいの 今回は公式のMySQLのDockerfileを読んでみようと頑張りました。この記事は長すぎたので2つに分割しています。こちらの記事はDockerfileに付随しているdocker-entrypoint.sh編です。 今回読んでみたのは以下です。 docker-library/mysql/5.7/ Dockerfile本体の記事はこちらです。ぜひ参照してください。 Docker公式MySQLのDockerfileを頑張って読んで理解しようとしてみた[Dockerfile本体編] それではdocker-entrypoint.sh編の始まりです。 エラー時の挙動設定 set -eo pipefail このシェルスクリプトではパイプ中のエラーでもちゃんと終了するようにpipefailオプションをつけています。ともかくちゃんと落ちろということのようです。 オプション
![Docker公式MySQLのDockerfileを頑張って読んで理解しようとしてみた[docker-entrypoint.sh編] | Unskilled?](https://cdn-ak-scissors.b.st-hatena.com/image/square/e3591dec3b06539bc5280f9adaf021dd29aa4117/height=288;version=1;width=512/https%3A%2F%2Funskilled.site%2Fwp-content%2Fplugins%2Fall-in-one-seo-pack%2Fimages%2Fdefault-user-image.png)
MySQLで処理に長時間かかっている複数クエリをまとめて殺す方法 | Basicinc Enjoy Hacking!
あまりにも処理に時間がかかるようなSQLを実行してしまい、MySQLがうんともすんとも言わなくなってしまうような状況、よくありますよね。っていうか、まぁそんな状況あってはならないんですが、時たまあります。そんな時、問題となっているクエリの処理を止めたいわけです。 特定のクエリを止める方法 MySQLで実行中のクエリ一覧を見て、SQLを強制終了する方法 こちらを見てもらえればやり方は分かります。単純にMySQLに入って、show processlist;で問題のあるクエリを発見し、プロセスIDを kill するだけ。とても簡単。 複数のクエリを一括で止める方法 今回は問題のあるクエリが100個あったらどうする…？的なのを解決するエントリーです。まぁ、問題あるクエリ100個ある状況は、アプリ的に問題あるんじゃね？っていうレベルですが。 1個ずつプロセスIDをコピペして…なんてやってられないです
Dockerの公式MySQLイメージの使い方を徹底的に解説するよ · DQNEO日記
DockerHubでは公式のMySQLイメージが無料で公開されています。 これを使えば簡単にDockerでMySQLサーバを起動することができます。データの永続化もできます。 https://hub.docker.com/_/mysql/ 2015年10月現在では下記３種類のバージョンが用意されています。 タグを指定することで任意のバージョンのイメージを取得できます。 5.5 5.6 5.7 (latest) イメージの取得方法 docker pull mysql これで最新の安定版を取得できます。 バージョンを明示的に取得したい場合はタグを使います。 docker pull mysql:5.7 (2015/10/25現在だと、mysql, mysql:latest, mysql:5.7, mysql:5.7.9はどれも同じイメージを指します。) これのDockerfileを見たい場合はこ
MySQLのmasterとslaveの手動切り替え - Qiita
半年間、MySQLを基礎からやり直すことにしたので、その間に勉強したことをQiitaに投稿していきます。 設定自体は、前回の続きになるので下記のリンクを参考にして下さい CentOS6.5にMySQL5.5.38をインストールする手順 MySQLでレプリケーションを組んでみる スレーブ側の設定 レプリケーション用のユーザ作成 スレーブ側で実行する 許可するネットワーク：XXX.XXX.XXX.XXX ユーザ名：repli パスワード：repli # ユーザの作成 mysql> GRANT REPLICATION SLAVE ON *.* TO 'repli'@'XXX.XXX.XXX.XXX' IDENTIFIED BY 'repli'; Query OK, 0 rows affected (0.00 # ユーザの確認 mysql> select user, host from mysql
mysql replicationの復旧方法
Master_Log_File, Relay_Master_Log_Fileの意味は混同しやすいので、細心の注意を払ってください。また、それぞれのポジションの実態は、master.info, relay.infoというファイルです。 mysql レプリケーション 復旧シナリオ 事前準備 mysql レプリケーション 復旧シナリオ 事前準備 – mysqld_multi環境の構築 mysqld_multiを用いて、3つのmysqld(MySQLサーバ)を起動させます。動作確認のシナリオで使用する/etc/my.cnfの設定は以下の通りです。mysqld_multiの使い方は、mysqld_multiの設定方法を参照ください。 [mysqld] log-bin=mysql-bin relay-log=mysql-relay log-slave-updates master_info_repos
MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary
この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの
mysqlのinnodb_log_file_sizeの設定を変更した時の対応
この記事でmysqlサーバの最低限の設定を書きました。 my.cnfのinnodb_log_file_sizeの値を変更したあと、そのままmysqlを再起動すると起動しなくなったり、起動してもselectやupdateができなくなります。以下の手順を踏むことで正常にもどります。一旦mysqlサーバを停止しないといけないので、場合によっては少し面倒くさい感じになるかもしれません。 ■mysqlサーバの停止 まずは、mysqlサーバを停止します。 /etc/init.d/mysqld stop ■ログファイルの削除 以下の2つのファイルを削除、または移動します。ファイルの場所は、yumでインストールした時は以下の位置にあります。都度読み替えてください。 rm /var/lib/mysql/ib_logfile0 rm /var/lib/mysql/ib_logfile1 ■mysql再起動 m
MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst
MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu
コマンド一つでMysqlを速くする - Qiita
稼働中のシステムであっても下記のコマンドを実行するだけで再起動等必要はないので、非常にお手軽に出来る。 デフォルトではinnodb_flush_log_at_trx_commit = 1 になっているはず。 1に設定するとトランザクション単位でログを出力するが 2 を指定すると1秒間に1回ログファイルに出力するようになる。 そのため、マスターDBが落ちて別スレーブに切り替わる仕組みを導入していても1秒の間に発生したトランザクションは完全にもとに戻す事が出来ない。 マスターDBの死 = サービス停止 みたいに冗長構成を持たせていないのならばこの設定にしても問題はなさそう。 mysqlslapでベンチマークを測ってみた。 テストの内容としては20クライアントから計10万回のINSERT文を実行するという内容で 結果として約3倍近く速くなっている。 innodb_flush_log_at_trx
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
mysql binlogからDB復旧 - Qiita
mysqlbinlogでDB復旧した時の自分用メモ。繰り返す自分用のメモ。 依頼内容 依頼者「2014-02-14の20時台に作業間違えた。なかったコトにしてもらえませんか。」 俺「・・・」 やりたいこと 2014-02-14の20時台に投げられたクエリをすべてなかったことにしたい。 作業手順 バックアップしたデータベースをリストアする mysqlbinlogで、リストアした時間（2014-02-13 03:30）から該当時間（2014-02-14 20:00）まで、ログ吐き出して適用 該当時間後の正常なデータを吐き出し。具体的に2014-02-14 20:59:59以降のデータを吐き出して適用 データ確認 && 差し替え 前提条件 binlogが吐かれていること 定期バックアップが取られていること binlogを吐く方法 /etc/my.confにbinlogの設定をする。 基本レプリケ
memolib.com - memolib リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ZabbixによるMS SQL監視 ～ODBC監視機能の解説～ - サーバーワークスエンジニアブログ
Zabbixでのデータベース監視と言えば、プリインストールのテンプレートでも監視できるMySQL監視が有名ですね。 【 Zabbix 2.0 】zabbix 2.0による簡単 MySQL 監視 #Zabbix from maoto qryuu どうも著者のくりゅうです。 さて今回はZabbixの解説本でも一部は説明があるもののいまいち使い方がわかりづらいであろう ODBC監視、データベースモニタの使い方について解説書を作りましたのでご紹介します。 Zabbixのアイテムの中にある「データベースモニタ」これはODBC接続を用いて任意のデータベースに接続をし、その中で指定されたSQLクエリを実行してその結果を取得する機能になります。 こう聞くとなにかと夢が広がる機能なのですが、実際にはZabbixのフロントエンドからの設定だけで完結するわけではありません。ZabbixServerがデータベース
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
モノのインターネットになぜNoSQLが必要なのか | readwrite.jp
リレーショナル・データベースは実に素晴らしいものだ。しかしモノのインターネットでのプロジェクトにおいてこれは実に役立たずだ。 少なくとも、数十億のスマートデバイスで構成される次世代ネットワークの管理について調査を行ったマキナ・リサーチによればそう言える。これによれば、リレーショナル・データベースは「構造化・均一化なデータの処理を処理するためのもの」であり、NoSQLデータベースは数えきれないほどのセンサー、デバイス、ゲートウェイから生成される、はるかに規模が大きく、不均一なデータのマネジメントの為に不可欠なものだという。 言い換えれば、もしあなたが開発者なのであればNoSQLデータベースを自分の武器として持っておく必要がある。 NoSQLが必要な理由“NoSQL”というそのありがちな呼称とは裏腹に、これは他のデータベースとは異なるものだ。NoSQLデータベースでは厳格なスキーマを強制しない
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://unskilled.site/docker%E5%85%AC%E5%BC%8Fmysql%E3%81%AEdockerfile%E3%82%92%E9%A0%91%E5%BC%B5%E3%81%A3%E3%81%A6%E8%AA%AD%E3%82%93%E3%81%A7%E7%90%86%E8%A7%A3%E3%81%97%E3%82%88%E3%81%86%E3%81%A8%E3%81%97%E3%81%A6/
mysql/mysql-server - Docker Hub
library/mysql - Docker Hub