InfluxDBではTICKスタックなるInfluxDBを中心とした時系列データを扱うツールセットを用意しようと計画している。そのうちのTが新しいメトリクスコレクタ(エージェント)、Telegrafである。なぜTelegrafを作ったのかや、今後の展開についてのまとめを記載する。 出典について この記事はInfluxDB BlogのAnnouncing Telegraf, a metrics collector for InfluxDB(2015/06/19)を翻訳したものです。 本日、我々はメトリクスを収集しInfluxDBに書込むオープンソフトのエージェントであるTelegrafの初期バージョンをリリースした。 Go言語で書かれており、新しいサービスやサードパーティーのAPIへのサポートを追加する為のプラグインが書けるようになっている。 今日現在で、Telegrafはシステム(CPU、

PostgreSQL, MySQL, SQL Server, Redshift上でIPアドレスを扱う際にどのようにすれば良いか、についてのまとめ 出典について この記事はThe High-Performance SQL Blog内のComparing IP Addresses in SQL(2015/06/24)を翻訳したものです。 イベントテーブルに操作を記録する際にユーザーのIPアドレスを保存するのは日常的な行為である。 今まで見てきた中では、大多数のケースではIPアドレスをvarcharで保存する。 この手法では、特定のIPアドレスに対してのクエリの発行は簡易となるが、データベースによってはIPアドレスの範囲でフィルタリングするのがきわめて難しくなる。 IPアドレスをvarcharとして比較すると誤った結果を返すことになる。 -- 100 is not less than 2, bu

免責事項 この記事はErlend Dahl氏によるMySQL Server Blogの投稿(2015/6/17)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 5.7の最初のリリース候補版(RC)のリリースから、次のサーバーのメジャーバージョンが急速に形になってきています。5.6がGAとなってからおよそ2年半にわたって、巨大な製品とコードベースを開発し維持する負担を軽減する為に、サーバーのコードの効率化に取組んできました。 この仕事の重要なところは、廃止予定(deprecation)と削除(removal)です。 機能を廃止予定とする(deprecating)ということは、我々が外部に「この機能は現在のところ利用可能である一方、将来のリリースで廃止されるため、利用の仕方にあわせて適応して欲しい」とお知らせしていることになります。機能を削除する(removi

MySQL Performance Blogの翻訳。MySQL Utilitiesに含まれるmysqldiffコマンドを使うと、サーバ間あるいは同一サーバ内でのテーブル定義の違いをチェックし、一致させるにはどうするべきかが分かる。使い方と簡単な仕組みの解説。 レプリケーション環境でデータの不整合が発生するのはよくあることでしょう。pt-table-checksumやpt-table-syncを使ってそういった問題を解決する方法を解説した記事はたくさんあります。多くの場合、データの整合性には気を使うと思いますが、サポート窓口では、以下のような質問を受けることもよくあります。 サーバ間でテーブル定義が一致しているか調べる方法は？ レプリケーションをしていても、マスタスレーブ間で異なったテーブル定義にしておくことは可能です。例えば、スレーブでは参照クエリのためにインデックスが必要だけれども、マス

MySQL Performance Blogの翻訳。rootパスワードが分からなくなった時の対処法としては、MySQLの再起動が必須になる方法が知られているが、本番DBではできる限り再起動を避けたいところ。そんな時に無停止でリセットするための裏技的な手順を紹介する。 December 10, 2014 by Daniel Guzmán Burgos 注意 : ここに書かれている方法は、自身の責任で実行する事。プラガブルな認証を使用している時はこの方法は使えない。また、MySQLのシステムテーブルがInnoDBにある時も同じく適用不可能だ。 状況 定番の「MySQLのrootパスワードをリセットしたい」という状況だが、MySQLの再起動はできず(本番のマスタなど)、--skip-grant-tablesを使ったリセット方法が使えない時。 (訳注 : MySQLの再起動が必要になるリセット方法

経験あるプログラマが初心者に言ってしまいがちだが、初心者のモチベーションに悪影響を与えるパターンを指摘する。言った方、言われた方、あるいは聞いたなど、何らかの形で誰もが身に覚えのある内容。 経験のあるプログラマと、プログラミングを習い始めたばかりの初心者の会話の例。 プログラマ : やあ、プログラミングの勉強を始めたんだって？いいじゃないか、何を勉強してるんだい？ 初心者 : PHPとHTMLの基礎をやってるんです。MacでTextMateエディタを使ってます。 プログラマ : ひええ、PHPなんて間抜けな言語かよ。Ruby on Railsを覚えて、Herokuにデプロイ、Vimでコーディングした方がいいよ。TextMateなんて初心者向きじゃないか。それから、Node.jsもやった方がいいな。あれはすっっっごくいいぜ。ノンブロッキングIOだからな。ヒャッハー！ 初心者 : うーん、そう

モダンなデータベースに使われる各種技術や運用に必要な知識について、Squareのデータベースエンジニアである筆者の見解。データベースの内部構造や仕組みについての興味をかき立てる。 昨年、私はSquareで色々なデータベースの面倒を見る中で、こんなことをしてきた。 データベースのパフォーマンス問題の調査と解決 新しいアプリケーションの、データモデルのデザインやシャーディング戦略の立案 データベース新製品の評価と運用化 最初は必要に迫られてやっていた私は、それから徐々に、データベースの虜になっていった。データベースを学ぶことは、コンピュータサイエンスのあらゆるトピックを横断的に扱うことであり、その理論や実装は、洗練され、かつチャレンジングでもある。 しかし、こういった感覚は他のみんなにも一般的なわけではないということも分かってきた。私の同僚や友人の多くにとっては、データベースは魔法のブラックボ

MySQL Performance Blogの翻訳。MySQLがサポートする4つのトランザクション分離レベルの特徴とパフォーマンス上の特性を、トランザクション履歴の保持方法に的を当てて比較。 January 14, 2015 by Peter Zaitsev 過去数ヶ月に渡って、InnoDBのトランザクション履歴の負債の危険性と、MVCCがMySQLのパフォーマンス問題の原因になりうることについて、いくつかの記事を書いてきた。この記事ではそれに関連して、InnoDBのトランザクション分離レベルとMVCC(multi-version concurrency control、多版型同時実行制御)との関連性、そしてそれらがMySQLのパフォーマンスにどう影響するのかを取り上げてみようと思う。 MySQLのマニュアルにはMySQLでサポートされているトランザクション分離レベルの詳細な説明がある。こ

MySQL 5.7.5の新機能である、InnoDBバッファプールのオンラインリサイズの動作概要に関して、InnoDBの開発者である木下靖文氏の解説。 MySQL 5.7のマニュアルにも書かれているように、MySQL 5.7.5からmysqldを再起動させずにバッファプールのサイズを変えることができるようになった。 これにより、SET GLOBAL innodb_buffer_pool_size = xxxxとコマンドを実行して、バックグラウンドでのサイズ変更ジョブを実行できるようになった。サイズ変更の進捗と状況は、innodb_buffer_pool_resize_status変数か、エラーログから確認できる。 メモリの確保と解放処理の影響を最小化し、トランザクション処理関連のタスクをブロックしてしまう大きなメモリコピー処理を避けるため、サイズ変更は一定のサイズのチャンク単位で行われる。I

MySQL Performance Blogの翻訳。Perconaのサポートエンジニアによる、MySQLバージョンアップの様々なパターンと、その利点・欠点、手順の解説。バージョンアップ実施前の、事前調査とテストが重要であるとの指摘も。 MySQLのバージョンアップ(訳注 : 原文ではupgrade、以下同じ)はどこかで必要になるタスクだし、我々Percona SupportでもMySQLバージョンアップのベストプラクティスについての色々な質問を受け付けている。この記事では、色々なシナリオにおけるMySQLバージョンアップの推奨できる方法に焦点を当ててみたい。 MySQLのバージョンアップはなぜ必要になってしまうのか？その理由は色々だが、新機能が必要、パフォーマンスの改善、バグ修正などがあるだろう。しかし、アプリケーションと組み合わせた上で事前に広範囲なテストをしておかないと、リスクの大きい

MySQL 5.6からの機能であるGTIDを、Facebookの環境に適用した際の流れと主な不具合、そしてそれらの修正点について、Facebookのエンジニアによるまとめ。 by Evan Elias and Santosh Praneeth Banda Global Transaction ID (GTID)は、MySQL 5.6の新機能の中でも最も使わずにはいられない機能の一つだ。このおかげで、フェイルオーバやポイントインタイムリカバリ、階層を持ったレプリケーションなどに非常に有益だし、クラッシュセーフなマルチスレッドレプリケーションの必須条件にもなっている。この数ヶ月で、我々はFacebookの全ての本番用MySQLインスタンスで、GTIDを有効にした。その中で、この機能の適用方法や操作について、たくさんの知見が得られた。たくさんのサーバサイドの修正事項については、WebScaleS

MariaDB監査プラグインのインストール方法、設定パラメータ、使い方について紹介。本プラグインはMariaDBだけでなくMySQLにも監査機能を提供。 WED, 2014/09/03 07:48 ANATOLIYDIMITROV データベースの環境を監視する上で監査は必須のタスクである。監査の情報はパフォーマンスやアプリケションの問題をトラブルシュートしたり、どのようなSQLクエリが処理されているのか正確に知るのに役立つ。 MariaDBの監査プラグインは、MariaDBだけでなく、MySQLにも監査機能を提供する。 MariaDBを公式のパッケージからインストールした場合は、標準でインストール済みでも有効化されているわけでもないがプラグインはシステム上にある。 server_audit.so(Linux)かserver_audit.dll(Windows)をプラグインディレクトリ(Ce

WED, 2014/08/20 11:47 ANATOLIYDIMITROV MariaDBでは、他のサービスと同様に最適なパフォーマンスを確保するにはユーザーのリソース使用量をモニターする必要がある。 MariaDBは、ユーザー毎に詳細な統計を提供し、それによってユーザーはデータベースサービスのモニタリングや最適化ができる。 ユーザーの統計は、共有の環境において、ある貪欲なユーザがサーバー全体の性能を低下させないようにするのにとりわけ有効である。 異常な利用を検知したら、これからみていくようにきめ細やかな制約を適用できる。 MariaDBでユーザ統計を有効にするには、サーバーのコンフィグファイル /etc/my.cnf.d/server.conf を編集する。 [mysqld]セクションに、userstat = 1を追記し、サービスを再起動する。 このタイミングから、MariaDBはin

MySQLのレプリケーション環境を運用していると、バイナリログへの記録を一時的に止めるためにsql_log_bin=0を実行したことがあるだろう。これを「set GLOBAL sql_log_bin=0」と、グローバル変数への変更として実行すると大変なことになる、という指摘。TwitterのMySQLエンジニア、Jeremy Cole氏の提言。 訳者注 2014.12.05 この機能はMySQL 5.5.41、5.6.22で使用できないように修正された。詳細は本文の最後を参照 もう4年半ぐらい前、コードのリファクタリングをしている最中に、sql_log_binは、SESSION変数としてだけではなく、GLOBAL変数としても使えるように決定されてしまった(あるいは間違って変更された？)。2年ほど前、TwitterでMySQL 5.5のアップグレードを実施していた時、その変更がいかに愚かで、

Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。 本発表はSQLアンチパターン著者のBill Karwinさんの発表です。 オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。 参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている