DBのメンテナンス
Zabbixで監視を長期間行うと、収集したベータによってDBのサイズが肥大していきます。 収集したデータは一定期間の制限があるので、ある程度まで肥大すればそれ以上は増えないように思えますが、実際にはフラグメントが発生して肥大を続けていきます。 このため、DBについては定期的にフラグメント対策していないと、気づいた時にはDB（またはディスクスペース）を食いつぶしてZabbixが動作できなくる事態が予想されます。 Zabbixで利用しているDBと各テーブルの使用サイズの確認 普通にインストールしたZabbixであれば、DBにはMySQL(innoDB)、DB名に"zabbix"が利用されている思われます。 この確認はZabbixサーバ上で次の操作で確認できます。 # mysql -u root -p Enter password: MySQLのパスワードを入力 Welcome to the M
Loading...
To manage workloads on Zabbix server Housekeeping feature should me more adjustable by adjusting start time of housekeeping event and/or inventing command line/frontend tools to initiate start of housekeeping process. At this moment there is only possibility to set amount of housekeeping operations in 24 hours. I would like to set also a start time of Housekeeping operations, for example, if house
zabbix2.2の新機能とか、hinemosとか、zabbixにposgreSQLとか
⋮ 0 0 zabbix2.2の新機能とか、hinemosとか、zabbixにposgreSQLとか Showing live article 1020 of 6875 in channel 1491816 Article Details: Author: Language: Japanese Channel Number: 1491816 Article Number: 1020 Date: August 29, 2013, 3:25 am URL: http://blog.goo.ne.jp/xmldtp/e/9a9eb328408639a7d55cf2cf79ac5605?fm=rss GUID: http://blog.goo.ne.jp/xmldtp/e/9a9eb328408639a7d55cf2cf79ac5605 ← $ X X Search Sharing: Title:
日々の覚書: REPLACE INTOが実はINSERT + DELETEだったと思ったら、結局DELETE + INSERTだった
REPLACE INTOが実はINSERT + DELETEだったと思ったら、結局DELETE + INSERTだった REPLACE INTOが実はINSERT + DELETEだった(INSERTが先で後から消す)の続き。 REPLACE INTOは「DELETE + INSERT(その行を消してからもう一度書く)」だと今まで思っていたけれど、 実は「INSERT + DELETE(行を突っ込んでから古い行を消す)」な動きっぽいというはなし。 そっちが先なんだびっくりー、という感じで書いたのですが、 色々手落ちがあったので後から調べたことをメモ。 1) その結果だと時間が一緒だから、「DELETEトリガーがINSERTトリガーより先」というのは断言できない。順番は必ずしも保証されないから。 ⇒TRIGGERの中身をSYSDATE(6)に書き換えてみました。 mysql56> delim
OOM relation to vm.swappiness=0 in new kernel
I have recently been involved in diagnosing the reasons behind OOM invocation that would kill the MySQL server process. Of course these servers were primarily running MySQL. As such the MySQL server process was the one with the largest amount of memory allocated. But the strange thing was that in all the cases, there was no swapping activity seen and there were enough pages in the page cache. Iron
せじまくんの刺さらない話（MySQL Slave増設編） | GREE Engineering
はじめまして。プラットフォーム開発本部のせじまです。好きなものはDisk I/Oです。 今回はMySQL（on Linux）のレプリケーションにまつわる、ちょっとしたお話をさせていただきたいと思います。 はじめに MySQL4.0以降のレプリケーションは、 Masterのmysqldが、INSERT/UPDATE/DELETEなどの更新情報を、バイナリログに記録する。 Slaveのmysqld(IOスレッド)は、masterのmysqldに接続し、バイナリログを転送する。 Slaveのmysqld(IOスレッド)は、受信したバイナリログ内容を、リレーログに記録する。 Slaveのmysqld(SQLスレッド)は、リレーログを読み込み、更新内容をslaveのDBに反映する。 といった仕組みになっています。図にすると次の通りです(*1)。 MySQLのレプリケーションはとても良くできた仕組みな
ROUND：小数点以下を四捨五入する
ROUND( 数値 ) 【注意】 ROUND関数を使用することでできるのは「数値を丸める」ことで、「四捨五入をする」ことではありません。 ただ一般的にROUND関数の動作を四捨五入という表現が使用されることが多いため、ページのタイトルを四捨五入としています。 「丸め」については後ほど説明しますが、「丸め」ではなく「四捨五入」を実現したい場合はFLOOR関数を使用して以下のように計算することができます。 --小数点以下第一位を四捨五入する FLOOR( 数値 + 0.5 ) --小数点以下第Ｎ位を四捨五入する FLOOR( 数値 * POW( 10, N-1 ) + 0.5 ) / POW( 10, N-1 ) --※上記の方法では負の数値の場合、ゼロの方向に丸めますが、 --逆方向に丸めたい場合は 0.5 の部分を 0.5 * SIGN( 数値 ) とする。 mysql> SELECT F
MySQLの新しいInnoDB ページI/O圧縮機能について解析してみた
InnoDBにはデータの圧縮機能がありますが、パフォーマンスが低いことからあまり使われていません。ただ今年の Percona Live で Oracle MySQL, MariaDB, そして Percona Server が新しい InnoDB Compression を出してきました。これはFusion-ioの R&D チームがフラッシュストレージ向けの MySQL 高速化の一環で開発したパッチが元になっています。ちなみに私は Fusion-io の社員ですのでこの発表をワクテカして待っていたのですが、折角コードが一般にリリースされたので、ソースコードを眺めて動作を調べることにしました。 参考にしたのは MySQL Server Snapshots (labs.mysql.com) にあるMySQL with InnoDB PageIO Compression のソースコード、およびM
SQL識別子エスケープのバグの事例
昨日のエントリに続いてSQL識別子のエスケープの話題で、今回は著名アプリケーションにおけるSQL識別子のエスケープ処理のバグについてです。 MySQL Workbenchには識別子のエスケープに関するバグがあった 以下の画面は、MySQLが提供するMySQL Workbenchの旧バージョン（5.2.34）の様子です（CentOS6.5上で動作）。MySQL WorkbenchはWebアプリケーションではなく、下図からも分かるようにGUIツールです。 下図では a`b というテーブルの内容を表示しようとして、エラーが表示されています。 生成されているSQL文は下記の通りです。 SELECT * FROM `db`.`a`b`; これは駄目ですね。SQL識別子中に引用符がある場合は、引用符を重ねるのがルールでした。つり、正しくは以下であるべきです。 SELECT * FROM `db`.`a
PHPでデータベースに接続するときのまとめ - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが， PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス～例外処理～PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります．付録にリンクを貼っておきましたので，「該当するかも？」という人はクリックして飛んで読んでください．太字にしてあるものは脆弱性に直結する危険度の高いものです． mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
SELECT ... FOR UPDATEとロックの挙動 - walf443's blog
kamipoさんが補足を書いてくれたので、参照するとよいです。 基礎的だけど、SELECT ... FOR UPDATEをちゃんと理解できてない気がするな、ということで実際にコンソールで打ちながら挙動を確認してみた。 今回確認した環境は、 mysql> show variables like 'tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | +---------------+-----------------+ 1 row in set (0.00 sec) mysql> show variables like 'version'; +-----
performance_schemaによる秒間接続数の性能差 - hiroi10のブログ
前回はperformance_schema(以下p_s)の無効、有効、有効でsetup_instrumentsテーブルのENABLED列を全てNOにした場合の性能測定を行いました。こちらは結果としてsetup_instrumentsテーブルのENABLED列を全てNOにするとp_sをOFFにした場合とあまり性能が変わらない所まで改善する事が確認出来ました。 p_sが有効にすると性能が下がるというのは松信さんのブログでも書かれているのでご存知の方も多いかと思います。今回はsetup_instrumentsテーブルの設定のより秒間接続数に差が出るか確認を行いました。 ベンチマーク環境は基本前回と同じです。但し、リモートからTCPにより接続する一般的なWEB・DBサーバの環境となるようにしています。今回はNICの情報等も追記しました。 ベンチマーク環境・サーバ側(OS/HW) CentOS re
RDSがMySQL5.6対応したのでベンチマークをとってみた - まめ畑
先日 Amazon Web Services Blog: MySQL 5.6 Support for Amazon RDS で、RDSがMySQL5.6対応(現在は5.6.12が最新)したということで簡単にベンチマークをかけてみました。 RDSはメジャーバージョンアップが簡単に出来るようになりましたが、5.6へのUpgradeはまだ対応していないので、dump->version up->importする必要があります。 今回RDSがMySQL5.6対応した際に5.6から導入されたMemcached Pluginが使用出来るようになったり、Binlogへのアクセス、innodbの新オプションが使えるようになっています。innodb_buffer_pool_dump_at_shutdownやGTID modeも有効に出来ます。 5.5からあるParameter Groupの中での変更点は in
MySQLでデータ領域をシステムと別diskにするならtmpdirも設定した方がいい - 酒日記 はてな支店
某所に300ホスト以上を2年ほど監視していたZabbixのMySQLがありまして、データが100GBぐらいになってメモリ8GBのホストではdisk IOが辛くなってきたので、移行することにしました。普段はそんなにでもないのですが、housekeeperが動作して古いデータを消しに行くとバッファプールに乗っていない部分に読みに行って重いのです。 この際折角なので Intel S3700 (サーバ用のSSD) をおごり、 Zabbix-1.8 から 2.0 にアップグレード MySQL-5.0.77 から MySQL-5.6.11 に変更 システムは HDD で /dev/sda1 データは SSD で /dev/sdb1 を /data にマウント という構成で移行の検証を行っていたところ… MySQLのバージョンが大きく上がるので mysqldump を取得して restore 後、pat
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.7.7.29 SHOW PROCESSLIST ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
チューニンガソン5の復習 MySQL 5.6 新機能編 - SH2の日記
というわけで、MyNA(日本MySQLユーザ会)会 2013年3月に参加して発表をしてきました。とてもリラックスして話をすることができました。司会進行の坂井さんをはじめ日本MySQLユーザ会のみなさま、日本オラクルのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは前回のエントリの続きということで、MySQL 5.6の新機能Optimizer Traceを活用しながら正攻法でのチューニングを行っていきました。とはいえ途中から正攻法ではなくなっていた気もします。MySQL 5.6でRDBMSとしての土台はしっかりしてきたと思いますので、今後は高度な統計情報を使用したSQL実行計画の最適化といったところにも機能強化が施されていくのではないかと期待しています。 プレゼンテーション資料 (PDF) EXPLAINとOptimizer Traceの出力結果 プ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLの観点から「Oracle Database」「PostgreSQL」 「MySQL」の特徴を整理しよう！
AWS Release Notes
Re: MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation
Rounding Errors in MYSQL with DECIMAL Type