You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Amazon Web Services ブログ MySQL5.7互換のAmazon AuroraでJSONを利用する MySQL 5.7でのJSONサポートについて重要な点は? MySQL 5.6では、数値、日付と時刻、文字列(文字とバイト)の型、および空間データ型をサポートしています。これらの型は広くサポートされていますが、これらの基本データ型は、アプリケーションを進化を作成する際の柔軟性を制限します。 MySQL 5.6を使用している場合は、アプリケーションに機能を追加する計画する際に2つの選択肢があります。最初のオプションは、アプリケーションで現在必要なすべてのフィールドを含む完全なスキーマを設定することです。その後アプリケーションで新しいフィールドが必要な場合は、スキーマを更新してその列を追加する必要があります。このアプローチにはいくつかの利点があります。新しいフィールドにインデッ
こんにちは、藤本です。 先日開催された Developers.IO 2017 で「Amazon Elasticsearch Service の使いドコロ」というタイトルで登壇しました。 Developers.IO 2017セッション「Amazon Elasticsearch Service の使いドコロ」で話しました #cmdevio2017 資料を作成する中で MySQL 5.7 から追加された全文検索の日本語対応に関して調べました。せっかくなのでまとめた内容をブログに書き出すとともに、RDS だとどこまでできるのかということを追加調査してみました。 MySQL 5.7 の日本語全文検索に関しては公式ドキュメントや、Oracle の方のスライドに詳しく説明されていますので、詳しく知りたい方は下記をご参照ください。 12.9 Full-Text Search Functions MySQL
はじめに MacOS上でレプリケーションを試してみるために、mysqld_multiを使ってMySQLを複数立ち上げようと思いました。 mysqld_multiに関する記事はいくつかありましたが、ハマった点が多くあったので、自分が最終的に出来たやり方をご紹介します。 やり方 /etc/my.cnfという設定ファイルを作成する [mysqld_multi] mysqld = /usr/local/bin/mysqld_safe mysqladmin = /usr/local/bin/mysqladmin user = multi_admin password = password [mysqld] [mysqld1] server-id = 1 socket = /tmp/mysql.sock port = 3306 pid-file = /usr/local/var/mysql/my.lo
4月にMySQLの日本語コレーションについて語り合う場に呼ばれていろいろ話を聞いてきました。すぐにブログを書こうと思ったんですが、はや2ヶ月経過…。 ときどき、自分がMySQLの文字コードに関して発表する際に、次のようなスライドをいれてるんですが、 MySQL 8.0 でとうとう日本語コレーションが入ることになったのに、なんか期待してたのと違いました。 で、その辺の話を聞きました(2ヶ月も経ってるのでうろ覚え)。 Q. わざわざ日本語ロケール作るんだったら日本人が扱いやすいロケールにしてほしい utf8mb4_ja_0900_as_csはMySQLが独自に考えたものではない。Unicode規格に従っている。過去にいろいろ独自にやって失敗してきてるので、もう独自にやるのは避けたい。 ai(accent insensitive)で「ハ」=「パ」=「バ」になるのも、ci(case insensi
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
MySQL Casual #6で@studio3104さんが発表していたnata2を触った。 My sql casual talks vol.6 from studio3104_com で、とりあえずローカルにnata2を起動しtd-agentを入れてプラグインを入れてmysqlslapを実行してみた。 動作環境はRuby2.1.2で。1.9系は動かなかった。 手順はgithubにも書かれているが、 https://github.com/studio3104/nata2 https://github.com/studio3104/fluent-plugin-nata2 以下は簡単な流れ。 まずnata2自体の設定。 git clone https://github.com/studio3104/nata2.git cd ./nata2 bundle install vim ./config
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ
最近うぇぶ業界では、開発効率や構築効率を求める動きが活発のように見受けられますが、ここで改善効率について手を伸ばしてみましょう。 改善効率とは、開発後期やサービス開始後の運用フェーズにおいて、クソコードやクソクエリ、データの蓄積によるレスポンスの悪化などを、自動的に検知し、開発者にオラオラ改修をプッシュするための仕組みのことでございます。 はじめに ここで紹介する内容はドリコムで実際に運用しているものですが、別にドヤ顔するようなものではなく、中規模以上の企業ならば似たようなことやそれ以上のことをやっているであろう、至極当然な内容です。それでも、それなりに種類が増えてきたことと、それなりの効果を得られていることが実感できているため、いったんまとめてみようと思った次第です。 ウチのサービスのサーバーサイドは Ruby on Rails + MySQL が基本なので、その対策手法になります。WE
概要 KLab株式会社さんの自家製ツールであるmymemcheckを使うと、my.cnf(もしくはSHOW VARIABLESの結果)をもとに、 最低限必要な物理メモリの大きさ IA-32のLinuxでのヒープサイズの制限 innodb_log_file_sizeの最大サイズ をチェックすることができます。 mymemcheckはDSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!からダウンロードできます。 構成 CentOS 5.6 (Final) MySQL Ver 14.14 Distrib 5.5.15, for Linux (x86_64) using readline 5.1 インストール CPANから必要なモジュールをインストールします。 # cpan install Readonly # cpan install UNIVERSAL::requireモ
昨日の記事 で innodb_support_xa = 0にすると RDS が速くなることを紹介したのですが、その後 Twitter で innodb_support_xa = 0 にするとクラッシュ時だけでなく通常時も binlog とトランザクションログの一貫性が無くなる(コミットする順序が前後する)可能性があることを指摘していただきました。 innodb_support_xa=0すると、トランザクションがコミットされた順番でバイナリログに載ることが保証できなくなるんだけどいいのかな? DSAS開発者の部屋:AWS RDS の書き込み性能チューニング dsas.blog.klab.org/archives/52108… — ts. yokuさん (@yoku0825) 2013年4月24日 実際に、 MySQL 5.5 と 5.6 両方で、 innodb_support_xa の説明に
ソースで、バイナリロギングが有効になっていることを確認し、一意のサーバー ID を構成する必要があります。 これには、サーバーの再起動が必要となる場合があります。 セクション17.1.2.1「レプリケーションソース構成の設定」を参照してください。 ソースに接続する各レプリカで、一意のサーバー ID を構成する必要があります。 これには、サーバーの再起動が必要となる場合があります。 セクション17.1.2.2「レプリカ構成の設定」を参照してください。 必要に応じて、レプリケーション用のバイナリログを読み取るときに、ソースとの認証中にレプリカで使用する別のユーザーを作成します。 セクション17.1.2.3「レプリケーション用ユーザーの作成」を参照してください。 データスナップショットを作成したり、レプリケーションプロセスを開始したりする前に、ソースで現在の位置をバイナリログに記録するようにして
MySQL 5.1からデフォルトで有効になっている便利な機能としてプロファイリングというものがある。MySQL 5.0でも利用出来たのだが、実験的な機能という位置づけであり、搭載されていたのはGPL版のMySQL Community Server限定だった。MySQL 5.1からは全てのエディションでプロファイリングを利用することができる。 プロファイリング機能を利用すると、クエリの状態(特に状態遷移やリソースの消費状況)を詳細に分析できるのでとても便利だ。MySQLエンジニア必携の機能といって良いだろう。というわけでプロファイリング機能の使い方を説明しよう。 MySQLサーバにログインしたら、まずは次のようにしてプロファイリングを有効にする。 mysql> SET profiling=1; すると、クエリの情報が記録されるようになる。次に、分析したいクエリを実行する。クエリはなんでもいい
MySQL 5.1で追加されたメジャーな機能の影に隠れた、地味だが便利な改善がある。それがスロークエリログに関する仕様である。MySQL 5.0まではスロークエリログは1秒未満のクエリを捕捉することが出来なかった。が、MySQL 5.1では1マイクロ秒までのクエリを記録できるようになっている。従って、0.5秒かかるけど大量に実行されてパフォーマンスに大きな影響を与えている!というようなクエリの発見が出来るようになった。1秒未満のクエリを追跡したい場合、例えば以下のような設定をする。 [mysqld] slow_query_log=ON slow_query_log_file=mysql-slow.log long_query_time=0.1 MySQL 5.0まではlog_slow_queryというオプションだったのが、MySQL 5.1ではslow_query_logというオプション名
アイドル状態(最後の実行から何もしていない)がN秒続くとMySQLが勝手に接続を切るらしい。 このN秒を設定するのがwait_timeoutである。 まず、デフォルト設定を確認してみる。 mysql -uroot -e'show variables' | egrep '(wait)'; -------- wait_timeout 28800 ということで、28800秒=8時間がデフォルトの模様。 http://dev.mysql.com/doc/refman/4.1/ja/gone-away.htmlにも書いてある。 次にwait_timeoutを10秒に変更してみる。 /etc/my.cnfに以下を追加。 [mysqld] wait_timeout=10 これで準備はOKなので、テストしてみる。 my $dbh = &get_handle my $sth = $dbh->prepare(
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く