MySQLのbinlogとredo logについて - Qiita
MySQLにbinlogとredo logの二つの重要なログシステムがあります。本文では、この二つのログの仕組みについて説明します。 #１．基本知識 MySQLは、SQLの解析と実行する機能を実現するServer層とデータアクセス機能を提供するストレージエンジン層で構成されています。ストレージエンジンには、MyISAM、InnoDB、Memoryなどが存在します。 binlogは、Server層が出力するログです。redo logは、InnoDBエンジンが出力するログです。二つのログは、ともにDBテーブル更新時に出力されます。 ディスクアクセスに時間がかかるため、InnoDBエンジンがメモリ上でレコードを更新し、redo log bufferに記録したら、レコード更新操作が完了とします。この仕組みは、WAL（Write Ahead Logging）といいます。別の専用スレッドが適当のタイミ
【k8s合宿】 Kubernetesのログ分析環境を作る - Uzabase for Engineers
こんにちは、SPEEDAのSREチームでエンジニアをしている阿南です。SPEEDAのSREチームでは、昨年末kubernetesについて理解を深めるために合宿を行いました。やり方はA〜Cの３チームに分けて、それぞれのチームでkubernetesに関することを調査、構築するという形式で、今回はAチームが実際にやってみた内容についてブログを書きたいと思います。（それぞれのチームでかなりボリュームがあるので、複数回に渡って連載的な形でお届けしたいと思います。） Aチームでは、kubernetesを本番環境に投入するにあたり、ログ収集周りをあまり調査できてないなと感じ、GCP上に環境を作ってみることにしました。 構築する環境 構築手順 クラスター構築 wordpress + MySQL構築 Fluentdイメージの作成 ConfigMap設定 DaemonSet設定 まとめ お知らせ 構築する環境
DynamoDB Streamのデータをsocket.ioを使ってブラウザに流す - Qiita
やること TwitterのストリームデータをKinesisを経由してDynamoDBに保存します。 DynamoDB Streamにデータを流し、ブラウザでストリームデータを可視化する 構成図 Twitter Stream → Kinesis → DynamoDB AWS Lambda Reference Architecture: Real-time Stream Processing awslabsのアカウントにそのままやりたいことがありました。動かすとKinesisにデータを流して、キャプチャの通りDynamoDBにデータを保存してくれます。 DynamoDB → DynamoDB Stream → Lambda → SNS http Notification DynamoDB Streamの有効化 キャプチャの箇所からDynamoDB Streamを有効化します トリガーを有効化し
サーバーレスでAuroraの実行中クエリをCloudWatch Logsへ出力する | DevelopersIO
大栗です。 RDSで障害が発生する一因として、想定外に長時間実行しているクエリが邪魔になっていることがあります。RDS for MySQLやAuroraの場合はSlow Queryで長時間実行されたクエリは分かりますが、実行が完了したものしか出力されないため現在動いているものはshow processlist;を実行して実行中のクエリを確認する必要があります。監視システムで定期的にRDSにログインして実行すれば良いのですが、面倒なのでEC2を使わずに実装してみました。 全体概要 Auroraの場合は、ストアドプロシージャ経由でLambdaを実行できます。この機能とMySQLが持っているスケジュール機能を利用します。 AuroraのEvent Schedulerでinformation_schema.processlistの内容を取得してlambda_asyncを呼ぶ LambdaでPROC
Is PostgreSQL good enough?
A log of some thoughts about freelancing, about indie, about making things. On the web. It's a web log. A blog. tldr; you can do jobs, queues, real time change feeds, time series, object store, document store, full text search with PostgreSQL. How to, pros/cons, rough performance and complexity levels are all discussed. Many sources and relevant documentation is linked to. Your database is first.
ログ解析にパーティショニングを利用してみよう | Let's POSTGRES
Hitoshi Harada ここまでで一通り分析を終えました。ある時点での分析を行うことももちろんのこと、継続的にログを分析していき結果を比較していきたいものです。今回のデータは6日ばかりを対象にしているためデータサイズは大きくありませんでしたが、1ヶ月、1年と経過するにつれてサイズが増大します。ここでは、分析を継続していくために必要なテーブルパーティショニング（分割）の技術についてご紹介します。パーティショニングについてはこちらでも紹介しています。併せてお読み下さい。 PostgreSQLにおけるパーティショニング 9.0 現在、PostgreSQLにおけるパーティショニング機能とは、単一ノードにおける水平分割です。つまり、1マシン上において、行を選り分けることでテーブルを分割します。世の中のRDBMSには垂直分割（列による選り分け）をサポートしたり複数ノード（複数のマシン上にテーブル
SQLを使ってログ解析をしよう | Let's POSTGRES
PostgreSQLを使ってアプリケーションのログ解析を行います。データを取り込み、WebのアクセスログをPostgreSQLの機能を活かして解析します。 SQLを使ってログ解析をしよう PostgreSQLを使ってアプリケーションのログ解析を行う手法を紹介します。まず初回はログをPostgreSQLのDBに取り込む方法と、それに関するノウハウについて解説します。 ログ解析にhstoreを利用してみよう 今回は、PostgreSQLのDBに格納したログデータを、hstoreを利用して加工しやすい形にする方法を紹介します。hstoreはPostgreSQLのcontribモジュールです。本記事では、複数の要素を持つtextデータを扱いやすくする方法を解説していきます。 ログ解析にWindow関数を利用してみよう (遷移/離脱) ログデータの具体的な解析方法を解説します。Webページのアクセス
SQLを使ってログ解析をしよう | Let's POSTGRES
各項目がカンマ区切りのテキストで1行を構成します。実際には下記のような内容です。 (注)幅の関係で1行のデータを2行に分けて記述しています。 ee1bdfe5b017f8dcddea61b54aa76536,2010-05-13 00:00:03,1,277,DoSearch,sort 安い順 region ハワイ country ハワイ島 ee1bdfe5b017f8dcddea61b54aa76536,2010-05-13 00:00:04,2,115,ShowList,sort 安い順 region ハワイ country ハワイ島 ee1bdfe5b017f8dcddea61b54aa76536,2010-05-13 00:00:06,3,344,DoSearch,date 20100701 sort 安い順 region ハワイ country ハワイ島 ee1bdfe5b017
ログ解析にWindow関数を利用してみよう (遷移/離脱) | Let's POSTGRES
夏目 伸彦 前回までで、ログデータを扱いやすい形のテーブルにしました。今回は具体的に分析を進めていきます。分析すべき内容はニーズによって様々ですが、今回は詳細ページへの遷移率、及びその他の要因との関係を見ていくことにします。 遷移と離脱 遷移率は検索画面において大切な指標になります。検索において、ユーザーが結果を見て次の画面に遷移するか離脱するかは、検索結果の品質や操作性が優れているか否かにかかっていると言えるでしょう。従って遷移率は是非知っておきたい情報です。さらに遷移したユーザとそうでないユーザを特定したとき、「それぞれがどのぐらいサイトに滞在していたか」や「サーバからのレスポンス時間がどうだったか」を調べると、検索サイトの改善ポイントが見つかるのではないかと仮定します。 まとめると、遷移したユーザと離脱したユーザがどれだけいるのか、またユーザーの遷移と相関のある要因はないか、というこ
ログ解析にWindow関数を利用してみよう(寄与度) | Let's POSTGRES
Hitoshi Harada 分析の対象として前回ではセッションをターゲットに行いました。ログデータにはパラメータの情報が残されており、この情報をうまく分析できれば何か知見が得られるかもしれません。 条件パラメータの寄与度を調べる どのような条件で検索した人が詳細ページまで遷移しているかがわかれば、Webサイトの最適化の一助となるでしょう。つまり、「最初の検索で行き先を指定した人の方が詳細まで遷移しているのか？それとも日付を指定した人の方が詳細まで遷移しやすいのか？」を調べることで、よりユーザフレンドリーなWebへの改善が見込めそうです。 行を返す関数 集めたログから条件の寄与度を調べるためには条件をキーとした集計をできれば良さそうですが、ログの単位はセッションやアクセス単位になっていて、なかなか条件をキーにした形にするのは難しそうです。 ここで、条件パラメータを hstore にしておい
稼動統計情報を活用しよう(2) — Let's Postgres
NTT オープンソースソフトウェアセンタ 笠原 辰仁 稼動統計情報を取得してみよう では、実際に稼動統計情報を取得してみましょう。稼動統計情報は、PostgreSQLのテーブルやビューの形で提供されています。pg_stat_* という名称のテーブル/ビューがそれらに当たります。そのため、取得にはSQLを用います。なお、psqlの\dコマンドなどでpg_stat_*のビュー定義を見てみると、pg_stat_get_*() 関数で各種情報が取得されていることが分かると思います。稼動統計情報を直接取得するには関数を使うのですが、それをビュー経由でユーザが閲覧できるようになっています。本項では、pg_stat_*で提供されているビューを読み解いていくことにします。 それでは、前ページの冒頭で紹介した情報について具体的に解説していきます。下記は稼動統計情報の中でも多用される情報ですので、覚えておくと
第14回 MySQLのヘルスチェックをする［応用的な死活監視編］ | gihyo.jp
MySQLを本番で運用する場合、ヘルスチェック（監視）は欠かせません。ヘルスチェックには大きく分けて死活監視（MySQLのプロセスが稼働しているかどうか）と傾向監視（レスポンスを悪化させるような兆候が表れていないか）の2つがあると思います。 今回は第12回から少し応用をきかせた監視方法を説明したいと思います。第12回で説明した事柄は今回は省略しますので、ご覧になっていない方は、先に第12回をご覧いただくことをお勧めします。 mysqlコマンドを利用した監視スクリプト データベースが問題なく動いているかどうかを確認するためにはMySQLの外側から監視する必要がある、という話を第12回の最後にしました。それでは、MySQLを外側から監視する簡単な実装を見てみましょう。サンプルということで、mysqlコマンドを利用したシェルスクリプトとして作ってみます。 #!/bin/bash export M
SQLを使ってログ解析をしよう | Let's POSTGRES
各項目がカンマ区切りのテキストで1行を構成します。実際には下記のような内容です。 (注)幅の関係で1行のデータを2行に分けて記述しています。 ee1bdfe5b017f8dcddea61b54aa76536,2010-05-13 00:00:03,1,277,DoSearch,sort 安い順 region ハワイ country ハワイ島 ee1bdfe5b017f8dcddea61b54aa76536,2010-05-13 00:00:04,2,115,ShowList,sort 安い順 region ハワイ country ハワイ島 ee1bdfe5b017f8dcddea61b54aa76536,2010-05-13 00:00:06,3,344,DoSearch,date 20100701 sort 安い順 region ハワイ country ハワイ島 ee1bdfe5b017
第7回 スロークエリーログを使って遅いクエリを収集する | gihyo.jp
最近ではPaaS型のクラウドがかなり普及しており、サーバを自分で用意しなくても簡単にサービスを公開できるようになりました。そのため、自分向けの便利サービスなどを作っている人も多いのではないかと思います。しかし、サービスの初期段階だとうまく動いていた機能が時とともに、だんだんと重くなっていき使いにくくなることもあるかと思います。 そんな時には、データベースに限った話ではありませんが、チューニングをしよう！と考えるかと思いますが、どこをどのようにチューニングすれば高速化が見込めるかは、しっかりと計測してみないとわかりません。当てずっぽうにチューニングした結果、実はあまり関係がなかったということもあるかと思います。 そこで、今回はMySQLに簡単な設定をすることで遅いSQLを記録するためのスロークエリーログを有効にして、チューニングのために必要な情報を収集できるようにしたいと思います。 デモンス
【1コマンドでOK】MySQLユーザーに贈る、スロークエリ解析の始め方 - コネヒト開発者ブログ
こんにちは！ CTOの島田(@tatsushim)です。前回の私の記事ではインフラ構成について触れました。 インフラを構築したらその運用が必要になりますね。今回は社内で行っているDBのスロークエリ解析について紹介したいと思います。 時間がない人向けに要点を3つにまとめると ママリでは定期的にクエリの見直し時間をとっている その理由は、レスポンスタイムがユーザーの滞在時間に大きく影響するため pt-query-digestを使うとカジュアルにクエリログを解析できるから初心者にもオススメ という感じです。それぞれについて解説していきます。 定期的にクエリの見直しをする 現在ママリでは、定期的にクエリの見直しをする時間を開発スケジュールに入れています。 それは、レスポンスタイムがユーザーの滞在時間に大きく影響するためです。 ORマッパーでコードを書いていると気づかないうちにスロークエリを発行して
スロークエリの分析 — Let's Postgres
NTT オープンソースソフトウェアセンタ 板垣 貴裕 スロークエリ (時間のかかるSQL) を発見するまでの手順を解説します。スロークエリ分析と改善は以下の流れで行うことになります。この記事では主に 1. のスロークエリの特定方法について解説します。2.については『スロークエリの改善』を参考にしてください。 どのSQLが遅いのかを見つける。 そのSQLがなぜ時間がかかるのかを判断する。 設定パラメータ、SQL、スキーマなどを改善する。 着目したSQLの性能を再測定し、2. から繰り返す。 着目したSQLのチューニングが完了したら、他のボトルネックを探すため 1. から繰り返す。 スロークエリの見つけ方 スロークエリを見つけるには、大きく分けて統計情報ビューを使う方法と、サーバログを使う方法の2つがあります。統計情報ビューを使う方法は PostgreSQL 8.4 以降でしか利用できませんが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Logstorage AWS 対応 - Amazon RDS 対応 -
Google BigQuery の話 #gcpja
GitHub - tech-sketch/pg_monz-trial