MySQL 5.7.6のPerformance SchemaでInnoDBのALTER TABLE進捗どうですか
MySQL 5.7.6で追加された新しいp_sのステージ情報から、 合法的に InnoDBに進捗どうですか？ を聞けるようになったらしい。 MySQL :: MySQL 5.7 Reference Manual :: 14.13.11.1 Monitoring ALTER TABLE Progress for InnoDB Tables Using Performance Schema setup_instrumentsでalter table関連のやつ(デフォルトOFF)と mysql> SELECT * FROM setup_instruments WHERE name LIKE 'stage/innodb/alter%'; +------------------------------------------------------+---------+-------+ | NAME
MySQLのオプションファイル オプションファイルとはその名の通りMySQL関連プログラムに渡すオプションを列挙したもので、Linuxプラットフォームでは/etc/my.cnfが有名です。Windowsプラットフォームではmy.iniというファイル名も利用されますが、今回はCentOS 6.6のyum版MySQL 5.6の構成を例に説明します（"yum版"の意図するところについては、第10回 yum, rpmインストールにおけるMySQL 5.6とMySQL 5.7の違いを参照ください）。 デフォルトでオプションファイルが読み込まれる順番 リファレンスマニュアルにも記載がありますが、デフォルトで読み込まれるオプションファイルは複数存在し、「読み込まれる順番」があります。 同じオプションを複数のオプションファイルで指定した場合は「後から読み込まれたファイル」の設定が優先されます（番号の
最近、Elastic BeanstalkやECSと戦っているSREチームの菅原です。 P5をやりたいのにPS3もPS4も持っていないので指をくわえて羨ましがっている毎日です。 この記事では、突然のアクセス増に備えるために、MySQLのスレーブを１〜２時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
私は如何にして詳解 MySQL 5.7を執筆するに至ったか
先日・・・といっても既に先月のことになるのだが、詳解MySQL 5.7 出版記念交流会には多くの方に来て頂いた。台風にも関わらず、とても多くの（60名ほど）の方に足を運んで頂いたのは、本当に嬉しかった。ここで改めてお礼申し上げる。 ありがとうございました！！ さて、交流会のときに使用したスライドを公開したので、興味のある方は見ていただきたい。 少しスライドを補足すると、MySQL 5.7の新機能にスポットを当てた本というのは、やはりニッチだと思う。しかし、MySQL 5.7を使いこなす上で、このようにまとまった情報は必須・・・というか、無いと話にならないだろうと思っていたので、出版するに至ったことは非常にありがたい。よくこんな企画をよく通してくれたなと・・・。G社さんの反応は、至って普通だったと思う。とはいえ、今後もMySQLを使っていこうと考えている人には必ず役に立つ内容だと信じているの
mysqldump 是MySQL的一个命令行工具，用于逻辑备份。可以将数据库和表的结构，以及表中的数据分别导出成：create database, create table, insert into的sql语句。当然也可以导出 存储过程，触发器，函数，调度事件(events)。不管是程序员，还是DBA都会经常使用的一个工具。 1. mysqldump --help mysqldump 的选项很多，我们看一下他的帮助文档： mysqldump Ver 10.13 Distrib 5.6.26, for linux-glibc2.5 (i686) Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corpo
MySQLと名前解決 MySQLにおいて名前解決は、コネクションの確立・認証のフェーズで利用されます。デフォルト（名前解決が有効）な場合のシーケンスはざっくりと以下のようになります。 IPアドレスがMySQL内の名前解決キャッシュに載っているかどうかを確認する （載っていない場合） IPアドレスからホスト名に逆引きをかける（getnameinfo） 得られたホスト名を正引きし、IPアドレスを得る（getaddrinfo） IPアドレスとホスト名の両方を使って、接続元ホストの検証をする（第17回 MySQLのユーザー管理について［その1］の2ページ目を参照） 検証に成功した場合、これ以降の「接続元ホスト」はIPアドレスまたはホスト名の「検証に成功したどちらか一方」を利用する ユーザー名、パスワードなどの認証に進む 名前解決が無効（skip-name-resolveオプションが有効）な場合
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
At Facebook we use MySQL to manage many petabytes of data, along with the InnoDB storage engine that serves social activities such as likes, comments, and shares. While InnoDB provides great performance and reliability for a variety of workloads, it has inefficiencies on space and write amplification when used with flash storage. A few years ago, we built RocksDB, an embeddable, persistent key-val
本日、 gh-ost のオープンソース・リリースを発表します。GitHubの、トリガーレスなMySQL向けオンライン・スキーマ・マイグレーション・ツールです。 gh-ost は、MySQLテーブルの修正が必要な、進行中の継続的なプロダクション変更に伴って私たちが直面する問題に答えるために、ここ数ヶ月で開発されました。 gh-ost は、負担が小さく、制御しやすく、監査しやすく、操作が簡単なソリューションを提供することによって、現在のオンライン・テーブル・マイグレーションのパラダイムを様変わりさせます。 MySQLテーブルのマイグレーションは、よく知られた問題で、2009年からはオンライン・スキーマ変更ツールによって対処されてきました。ハイペースで成長するプロダクトに伴って、データベース構造の変更が必要になります。列やインデックスなどの追加・変更・削除は、デフォルトのMySQLの動作を妨げる
Redirecting… Click here if you are not redirected.
前回の第24回 GTIDを使用したレプリケーション構成を作成する［1］に続いてGTIDについて紹介します。今回は、レプリケーションがエラーで停止してしまった際の対処方法と、MySQL5.7から可能となったオンラインでのGTIDの有効化について説明します。 特定のトランザクションをスキップする 従来のレプリケーションでは、Duplicate entryなどのエラーにてレプリケーションが停止してしまった場合に、SET GLOBAL sql_slave_skip_counter = Nを使用してトランザクションまたはSQLステートメントをスキップすることで、レプリケーションの継続ができました。しかし、GTIDを使用したレプリケーションではこの構文が使用できません。 GTIDを使用したレプリケーションでの対処方法として、以下の2点があります。 空のトランザクションを使用した方法 gtid_purg
本連載もついに最終回となりました。 本連載では、MySQLクエリーチューニングことはじめで予告した通り、「チューニング箇所の洗い出しのテクニック」について説明してきましたが、「チューニングの方法」については一切触れませんでした。 「本連載ではチューニングそのものの方法については詳しく説明しません。それは見出しの通り「銀の弾丸」などはなく、MySQLのパフォーマンスチューニングは計測と改善を繰り返し行っていくべきものだからです。そのため、特定のケースにマッチする改善の手法よりも、繰り返し使われる計測の手法にフォーカスを当てて説明していきます。」 その理由としてこの一文が全てではありますが、今回は参考までに筆者が考えるチューニングの指標を紹介したいと思います。それがあなたの環境に当てはまるかどうかは、これまでに紹介してきたツールなどを利用して計測してみてください。 チューニングの基本方針 基本
絵文字（UTF-8 の 4 byte 文字にあたる）を利用可能とするため、文字コードは utf8mb4 を利用する。 絵文字だけでなく非常用漢字なども対応するためには必要。 サーバ設定 とりあえず開発環境（Mac）は Homebrew でインストール brew install mysql （検証時点で 5.7.13）。 サーバの設定を以下のとおり変更する。 $ diff /etc/my.cnf.org /etc/my.cnf --- /etc/my.cnf.org 2016-07-05 18:46:02.000000000 +0900 +++ /etc/my.cnf 2016-07-15 14:43:47.000000000 +0900 @@ -16,7 +16,7 @@ # The following options will be passed to all MySQL clients
While all three systems are able to scale linearly by adding new nodes online, only a couple systems can also receive writes during failover. None of the solutions have a built-in way of notifying downstream dependencies of changes, so we would need to implement that at the application level. They all have indexes, but if you’re going to index many different values, the queries become slow, as the
DB Tech Showcase Tokyo 2016 で発表しました。MySQL 5.7の新機能 〜InnoDB編〜
表題の通り、db tech showcase Tokyo 2016にて、MySQL 5.7の新機能についての解説を行った。スライドをアップロードしたので、セッションに来てくれた方も、見逃したという方もぜひ見て頂きたい。 What's New in MySQL 5.7 InnoDB from Mikiya Okuno 思えば、4年前のdb tech showcaseでMySQL 5.6の新機能について解説したときは、1回のセッションですべての機能を詳解することができた。ところが、MySQL 5.7に至っては、昨年MyNA会でオプティマイザ関連の新機能についての解説を行ったのに続き、今回はInnoDBの新機能だけに的を絞った解説となった。このように小出しにしているのにはワケがある。いや、そもそも小出しにしているというつもりはない。単にMySQL 5.7の新機能が多すぎて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
