マスター/スレーブ構成(そもそもスレーブいなければcheck_slave_lagもへったくれもない) pt-osc, pt-tcsなどはマスターサーバーで実行する check_slave_lag用にユーザーを作る(図の実線部分を担当するためのアカウント) 短期間でDROPするのが前提で、色々面倒なのでスーパーユーザーで行く。FILE権限くらいは確実に要らないからREVOKEしとくか。。
この投稿は? すでにあるMySQL/MariaDBから、ER図を作成するまでの説明です。 自分用メモでもあるので、文字ばかりです。 とても簡単なので、問題ないはず。 わからなければコメントください。 何を使うの? MySQL Workbenchを使います。 http://www-jp.mysql.com/products/workbench/ ダウンロードしてインストールしちゃってください。 ダウンロードページに進むと、いつもどおり(?)「OracleのWeb Account作りなよ!」といわれますが、 スルーしたい場合は Login / Sign Up ボタンの下にある No thanks, just start my download. リンクを押下して、ファイルをダウンロードすることもできます。 ER図を作ってみよう MySQL Workbenchを起動し、上部メニューから下記を選択
quickstack is a tool to take call stack traces with minimal overheads. There are a couple of tools to take stack traces such as gdb, pstack, but these tools have serious overheads. In many cases, target process stops for 0.2-N seconds. So it is dangerous to use such tools in production environment. quickstack makes it possible to take stack traces in less than 1 milliseconds. This is much smaller
TL;DR MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。 ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は mysql40dump のようなラッパーを何かしら作る必要があります(レプリケーションの情報はテーブルに保存されていてそれはダンプに含まれるから
2017/12/04 追記 レプリケーションの手順に誤りがあります。 無停止で前日のdumpからスレーブを作って同期をとった、から ↓↓↓↓↓↓↓↓↓ メンテナンスモードでマスターへの更新を止めた状態でdumpをとり、スレーブを作って同期 その後にメンテナンスモードをオフして、マスターへの更新を再開 という内容に更新予定です。 設定当時はよくわかっておらず、最初は更新を止めずに雑にレプリケーションしていました。 結果、複数のレコードを喪失したままレプリケーションが実行されていたので、やり直しています。 はじめに my.cnf のチューニングと計測がいったん終わり、MySQLサーバー(5.5)が安定稼働してきました。 そこで 今まで稼働を停止していた レプリケーションサーバーを再稼働させた時のことをまとめたいと思います。 手順周りは、作業しながらのメモから書き起こしたもので、多少雑な面がある
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
by @dekokun on 2014/05/31 20:46 Tagged as: MySQL. どうも。先日結婚式を挙げました。二次会のために手作りの巨大くす玉を作るノウハウを手に入れましたのでそのあたりもいずれブログに書きたいですね。 概説 MySQL5.6.5から、DATETIME型でも行の生成時刻と更新時刻を自動更新できるようになりましたよ。 方法 作成時刻は DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP で 更新時刻は DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP で宣言しましょう 参照:How do you set a default value for a MySQL Datetime column? 以下、MySQL5.6.17で検証
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0 | MySQL Server Blog (ユーザーによる日本語訳: 寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst)で言及されていた日本語用の照合順序 utf8mb4_ja_0900_as_cs 。 mysql80> SHOW COLLATION LIKE 'utf8%ja%'; +-----------------------+---------+-----+---------+----------+---------+ | Collation | Charset | Id | Default | Compiled | Sortlen | +-----------------------+-
最近,環境ごとのデータベーススキーマの差分をチェックする機会があった.プロダクション環境とステージング環境ならまだしも,開発環境だと検証のために追加したインデックスがそのままになっていたり,開発が途中で止まってしまって日の目を見ることがなかったテーブルが残っていたり,そういうことって比較的あるのではないかなと思う.特に今の環境だと,マイグレーションの仕組みが整っていないという課題もあり,より一層,データベーススキーマに差分が出やすくなってしまっている. 今回は MySQL から公式に提供されている mysqldiff というツールを使ってデータベーススキーマの差分をチェックした. mysqldiff をインストールする mysqldiff は MySQL Utilities という MySQL の管理ツールパッケージの中に同梱されている.現在だと v1.6 が最新になっている. MySQL
追記 MySQL 5.7.19か20あたりで取り込まれたパッチにより以下の問題は発生しなくなりました。つまりはバグでした。 InnoDB memcached pluginはMySQL 5.6から搭載された機能で、Memcacheプロトコルを使ってInnoDBにデータを読み書きできる便利機能です。 簡単なプロトコルなためSQLより高速に動作する点、InnoDBに記録できる点、MySQLのレプリケーションが利用できる点など、 うまく使えば便利な仕組みですが、結論を先に書いてしまうと使えなかったという話をします。 使えなかった理由 MySQL memcached pluginを使ったInnoDBへのインターフェイスが使えなかった理由はクラッシュが多発するためです。 高速な動作、レプリケーション機能などはうまく動作しているのですが、 しばらく動作させていると get 操作の際に SIGABRT と
ワンライナー mysql -u ユーザ -pパスワード -h 接続先 -e "SQL文" | sed -e 's/\t/\" \"/g' | sed -e 's/^/\"/g' | sed -e 's/$/\"/g' | sed -e "s/^/$(date '+%Y%m%d %H:%M:%S') /g" >> ファイル パスワードを生テキストで書くなって人はゴニョゴニョしてください。 追記:ゴニョゴニョするはなし、書きました。 MySQLで幸せになれるヤツの続き-パスワードを隠蔽する方法 - なからなLife 取りたい情報に応じて、権限が異なります。DBのroot相当の権限があるといいのですが、少なくとも「全スキーマへのSELECT」と「PROCESS」は必要になるはず。 何するやつ? MySQLにログインして、-eの後に指定したSQLを実行して、ログアウトする。 SQLの結果をパイプで
pt-query-digestだったり調査のために、N秒間だけmysqlの全クエリのログを取得したいということはよくありますよね そんな時はこんなコマンドを使うと簡単に指定の秒数slowlogを切り替えて保存、取得後に元に戻してくれます。 $ slowlog.pl --duration 10 -- --default-extra-file=/hoge/my.cnf -uuser -- のあとはmysqlコマンドに渡すオプション ソース #!/usr/bin/perl use strict; use warnings; use IO::Handle; use Getopt::Long; use File::Spec; sub find_path { my $pg = shift; my $path; for ( split /:/, $ENV{PATH} ) { if ( -x "$_/$p
この記事は MySQL Casual Advent Calendar 2016 の23日目の記事です。 そしてどうやら、 日々の覚書 の400本目の公開記事です。そんなに書いてたのか。。 前回 のあらすじ。 mysql57> SHOW CREATE TABLE game_score\G *************************** 1. row *************************** Table: game_score Create Table: CREATE TABLE `game_score` ( `seq` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `game_id` int(11) NOT NULL, `user_id` int(11) NOT NULL, `play_end_time` datetime N
Keep your databases in control with the fabFORCE DBDesigner4. Whether you have to design an new database or manage your data and models. DBDesigner4 Online Forum fabFORCE provides OpenSource utilities, components and infos for Kylix and Delphi programmers. All released under the GPL. Utilities Components Kylix Infos Film, video and music production, editing and post production. 3D animation and im
MySQL Casual Advent Calendar 2016 - Qiitaの6日目の記事です。 AdventCalendar自体初参加でドキドキ、してたら、成り行きで2日連続。 コレ用のきれいなエビデンス取れるような環境要していなかったので、普段より荒っぽいですが、Casualな感じで失礼します。 大きなテーブルを繰り返しSELECTしてたら、挙動が変わったんですよ。 バッファに載っているなら載っているで早いだろうし、載っていいなら最初ガッツリ遅くて、次からグイっと速くなるだろうと思っていたんですよ。 バッファに載りきらないなら、何回やっても遅いだろうと思っていたんですよ。 で、ちょいと計測的なことをやってた関係で、同じSQLを何度か叩いて平均、中央を見ようと思っていたんです。 そしたら、 45.71秒、44.90秒、24.44秒、13.32秒、13.12秒・・・ と、段階的に応答
MySQLで大量のレコードをDELETEする方法をいくつか試してみました。 (2016/9/17追記) 書き漏れましたが、MySQLは5.6.30で実験しています。 mysql> select version(); +-----------+ | version() | +-----------+ | 5.6.30 | +-----------+ 1 row in set (0.02 sec) (2016/9/17追記終わり) テスト用テーブル作成 まずテスト用のテーブルを用意します。0から9の値が均等に配置された1千万レコード。ほんとは1億レコードでやりたかったんだけど、さすがに時間が掛かりすぎたのでパス。 mysql> CREATE TABLE seed ( -> value INTEGER UNIQUE -> ) ENGINE=InnoDB; Query OK, 0 rows aff
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く