mysqlfailover で自動フェイルオーバーを実現する | スマートスタイル TECH BLOG
mysqlfailoverとは？ mysqlfailover はOracle社が提供している MySQL Utilities というツール群の中の1つです。 下記の図のようにレプリケーション構成において、マスターに障害が発生した場合、スレーブをマスターに切り替えるフェイルオーバー処理を自動で行うツールです。 検証MySQL環境構築 今回の検証ではdockerを使って マスター1台（node1）、スレーブ2台（node2, node3）、mysqlfailoverを実行するマシン（admin）の4インスタンス構成で行います。 設定ファイル docker-compose.yml version: '3' services: node1: image: mysql/mysql-server:5.7 environment: - MYSQL_ROOT_PASSWORD=password volum
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
日々の覚書: MySQL 8.0では「GROUP BYによる暗黙のソート」がされなくなるよ
GROUP BY implicitly sorts by default (that is, in the absence of ASC or DESC designators), but relying on implicit GROUP BY sorting in MySQL 5.7 is deprecated. $ perl -ML -E 'for (my $n= 1; $n <= 10; $n++) { for (my $m= 1; $m <= 100; $m++) { printf("%d\t%d\n", $n, $m) } }' | sort -R > /tmp/seq mysql80 165> CREATE TABLE t1 (n int, m int); Query OK, 0 rows affected (0.05 sec) mysql80 165> LOAD DATA
MySQLのInnoDBプライマリーキーのチューニング | Yakst
[MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2055日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに
MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
MySQL SQLとbashヒアドキュメントをうまく使いこなそう！！ - Database JUNKY
MySQLとヒアドキュメントをうまく使いこなされば、さくっとSQLをファイルを作ることができます。はじめは戸惑いますが慣れれば簡単です。数百回はやったかも（＾＾;） ヒアドキュメント（heredocument)自体は、MySQLとはまったく関係のない話、そもそもbashではありますが、MySQLとbashヒアドキュメントの相性は大変良いので、この機会に覚えておいたほうが良いかもしれません。 また、ヒアドキュメントを有効に活用できるようになれば、プログラムを作らなくても、シェルスクリプトだけで、バッチ処理を作ることも可能になり、なんにせよ、高速です！（プログラムが遅いっていっているわけではありませんのでそのは誤解しないでください） ヒアドキュメントを使って、SQLファイルを作成する例 今回の例で、EOT の名前にしましたが、別に、DOCでも良いし、とにかくEOT ～ EOTの間が文中でかぶら
サイボウズ版 MySQL パフォーマンスチューニングとその結果 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
MySQLがメモリー不足の時に何をするか : トラブルシューティングガイド | Yakst
MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 1948日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ
さいきんのMySQLのJSONまわり | GREE Engineers' Blog
こんにちわ。せじまです。 さいきん、しばしば庭園や日帰り登山に行って風景写真を撮っているのですが、カメラで写真を撮るという行為は（中略）実行計画を考えながらSQLを書く行為に近しいことだと思いますので、エンジニアの方にはけっこうオススメです。 今日は軽めの話をさっくりさせていただこうかと思います。 はじめに 皆さんは最近のMySQLがJSON型をサポートしているのをご存知でしょうか。「なぜ正規化されていないJSONをRDBMSに格納するのですか！正規化しましょう正規化」という至極ごもっともなご意見もあるでしょうが、 MySQLは5.7からJSON型のサポートをはじめ、8.0でかなり開発が加速している印象を受けます。JSON型がネイティブでサポートされるようになったのは、MySQL5.7のRelease Candidate以降です。5.7 RCがリリースされた2015年あたりから、MySQL
MySQLのZero Dateへの対処法
MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基本的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー
MySQLでトランザクションの挙動を試すためのツールを作った - tom__bo’s Blog
mytxという、トランザクション分離レベルの違いを調査したり、並列するトランザクションでどのようにロックがかけられているかを実験するためのツールを作りました。 mytxとは MySQLで分離レベルごとの挙動を実験しようとした時に、ウィンドウを複数開いて順番にコマンド叩いていくのが面倒だなーと思ったので作りました。 github.com gihyoの第50回 トランザクション分離レベルを試してみるでもやっているような、トランザクションごとにコネクションを張って、ウィンドウを行き来しつつコマンドを打って、場合によっては確認用のウィンドウも作ってロックの状況を確認して、とやるところを、予めSQLをファイルに用意しておくことで簡単に試せるようになります。 これくらいなら他のDBにも対応しようと思えば出来ますが、今はMySQLを対象にしています。 例えば2つのトランザクションを次のような順番で実行し
MySQL(innodb)の分離レベルごとのanomalyについて実験した - tom__bo’s Blog
※ この記事はMySQL Casual Advent Calendar 2017の11日目の記事です。 A critique of ANSI SQL isolation levelsを読んで(読んだブログ)、MySQL(innodb)で分離レベルごとのanomaly(不整合)の発生について実験しました。使ったのはDockerで立てられる 8.0.3-rc-log MySQL Community Sereverです。 ここでは上記の論文であげられているanomalyとid:kumagiさんのブログ(いろんなAnomaly)で知ったread only anomalyが起こるかを分離レベルごとに試してみます。 最初に、それぞれのanomalyについての簡単な説明とkumagiさんのブログで使っている書き方を真似た図、それに対応するプランを整理し、(実行経過は省略してw)結果だけ書きます。 ※ こ
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
MySQL 5.7のマルチソースレプリケーションを活用する - 無停止でシャーディングを解消 - 猫でもわかるWebプログラミングと副業
はじめに この記事は ドワンゴ Advent Calendar 2017 - Qiita の15日目の記事です。 昨日の記事は ytanaka さんの Goadを使った負荷試験とパフォーマンス分析手法について - Qiita でした。 自己紹介 ドワンゴでニコニコ動画の開発をしています。 *1 去年もアドベントカレンダー書いてました→ LGTM画像を驚くほど簡単に作れるWebサービスをScalaで作る - Qiita DBすき yoshikyoto (Yoshiyuki Sakamoto) · GitHub うたかた/ヨシキ (@yoshiki_utakata) | Twitter 背景 昔々あるところに、以下のような構成のサーバーがありました Webサーバー（アプリケーションサーバー）とDBサーバーからなる。 DBに入っているデータはユーザーIDでシャーディングされている。*2 どのデー
寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst
これまでのMySQLでよく問題になった、絵文字や日本語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GithubエンジニアリングがMySQL高可用性のために新しいアーキテクチャを採用
MySQL InnoDB Cluster を使って運用を手抜きしよう
スレッドIDを利用したMySQLのデッドロック解析手法
pixivにおけるMySQL運用の実際
MySQLアンチパターン
