以前のこの投稿
Zabbixの設定のみをバックアップする (Zabbix 3.0)
からいろいろ修正、Zabbix 3.4への対応なども含めてCLIツールをリリースしました。
GitHubなどでも同様のツールは見かけますが、リストアまで含めて対応しているものであったり、3.0よりも新しいバージョンに対応した物はほとんど見かけなかったので。
lf-uraku-yuki/zabbix_db_config_backup: Zabbix DB Config Only Backup Tool
https://github.com/lf-uraku-yuki/zabbix_db_config_backup
これをcronで定期的に叩いて差分バックアップを取り続ける事で、任意の時点への設定巻き戻しが可能になります。巻き戻した時点までの監視ログは、整合性確保の為に消失しますのでご注意ください。
また、無保証ソフトウェアとなりますのでその点も何卒。
2017年10月23日に開催された「MyNA(日本MySQLユーザ会)会 2017年10月」に参加してきました。このユーザー会へは初めて参加しました。
MySQL 8.0 RC リリース記念 という事で、MySQLプロダクトマネージャーのMorgan Tocker氏によるMySQL 8.0の全体像についての解説、ボリューム盛りだくさんな質疑応答が有り、他にも@yoku0825さんによる「MySQL 8.0で憶えておいてほしいこと」、 @naotoogawaさんによる「X Protocol はじめました(Haskellで ?)」が有りました。
Morgan Tocker氏の解説は分かりやすいスライドに、実例有り、分かりやすい日本語訳も有りでした。私はDB担当としてMySQLを触っているというよりは、作っているアプリケーションの一部として構築したりSQLを書いたりDDLを叩いたりチューニングしたりしている、といったぐらいなので知らない部分もかなり多かったです。
With句（CTE）、ウィンドウ関数導入、JSON関連対応の強化だけでなく、Unicodeへの対応強化とマルチバイトの高速化（デフォルトがutf8mb4になるだけじゃない）、GISの標準準拠（OpenGIS）の進展、ロックを制御する構文 SKIP LOCKEDなどなど。
MySQLは基本的に新しくなるほど高速化を続けていますが、マルチバイトで高速化しているというのはそれだけでもうメリットが大きそうで嬉しいですね。パフォーマンス面は5.7で主に読み込みが強化されましたが、8.0では書き込みも高速化されているようです。
質疑応答は「sli.do」というサービスを使って質問を募り回答するという形式。他の人の質問に対して投票をする事ができるのが面白く、票を多く集めた質問から聴いていくといった事が出来るのはなかなか新しいです。
質疑応答は本当にボリューミーかつ深い質問も多く、私にはもう分からないレベルの物もちょくちょく有りましたが、刺激的でした。印象に残っているのは「（Oracleの）MySQLへの投資は良い意味で変わっていない」という言葉、OracleをMySQLのアップデート先とも考えておらず、別のユーザー層が有り、それぞれ大切にしていくというようなニュアンスだったと思います。この部分は正直な所ちょっと意外でもありました。
また、どこまでスケールするかという質問では、正直な所分からないが(CPU以上に)IO周りの最適化が大切になってくる、との事でした。intelのOptaneなど、今までのSSDとも少し違う新ジャンルのストレージ技術によってDBの世界もどんどん変わっていくのでしょう。
サポート面では、8年間サポートを続けるために、3つのGAが保守中として残るような感じ？にしているなど、MariaDBとの方針の違いとしての話題も有りました。
各種パラーメータを自動で調整してくれるようになる innodb-dedicated-server は本番環境向きであり、開発環境には向かないというのも個人的にはちょっと意外でした。
他にも本当に様々な話題が有り、オフレコ扱いであるような部分も有り、貴重なお話でした。
「MySQL 8.0で憶えておいてほしいこと」ではおなじみとなった「ハハ=パパ問題」や微妙なデフォルトcollationだけでなく、MySQL 8.0で結構な数の予約語が増えている点での盛り上がりが有りました。”path”など、既存のアプリケーションで使ってそうな物も有り、注意点として大きそうです。
MySQL :: MySQL 8.0 Reference Manual :: 9.3 Keywords and Reserved Words
https://dev.mysql.com/doc/refman/8.0/en/keywords.html
例えばPHPだと各種フレームワークやライブラリのクエリビルダを使っているとこの辺はカラム名もエスケープしてくれていたりしますが、こういう時に助かるんですね。生のSQLを書いている箇所は見直そうと思います。
XProtcolを実装したセッションでは、名前と存在は知っている程度のXProtcolの中身がどうなっているのか、実際に実装するためにはどのファイルを参照すればいいのか、メタデータの扱い等、これもまたなかなか聴けない話題でした。
プロトコルを実装するためにはやぱりパケットの中身をみたりなど、低レイヤーの知識も必要になってくるのですね。言語によって実装に違いがあったりなどもするようで、罠も多そうな印象でした。
初MyNA会は、私のような雰囲気でDBを保守・チューニングしている人にはレベルが高い部分も多々ありましたが、全体として分かりやすく出来ていて、知らなかった事、ここでしか聴けなかったであろう話盛りだくさんでとても良かったです。既存のまだ残っている5.6を5.7に移行しつつ、MySQL 8.0の良い所活用していきたいです。
ーーーー
また、ここ2か月間、いくつかのジャンルのカンファレンス(セッション)や会に出てみて、どのジャンルでもやっぱり「出来る」人のレベルは普通の人とは全然違うなと改めて感じました。
自分自身は、特に何の高レベルでもなく、Bootstrapを導入してちょっとCSSをカスケードして調整する程度のHTML/CSSであったり、ググりながらJavaScritpでPOST送信・結果取得のような事をしてみたり、PHPでがりがりバックエンドの処理、SQL、バリデーション、DB CRUDを書いたり（でも本格的なオブジェクト指向、ドメイン志向設計には未だ弱い）、LinuxやDBのセットアップ、チューニングだったり（トラブル時の対処は本職のサーバーエンジニアには及ばない）、AWS上の各種ネットワークやRDS、LB、WAFを設定したり、Zabbixでのモニタリングをいじっていたり、どれについても薄いレベルでしか触っていない現状。今後どこに行っても新人レベル（吸収力で言えば新人以下）でしょう。やはり何かしらに絞って掘り下げていく（=環境も変える）べきなのだろうか……。だからと言ってどれにしようかというと。
OSSのサーバー監視ツール Zabbix はMySQL（やPostgreSQLなど）にデータを保存するのでDBのダンプ（とzabbix_server.conf）を取得しておけば概ねのバックアップが可能ですが、ログデータ（ヒストリ、トレンド）が巨大なデータになりがちです。おそらくログ系のテーブル以外をバックアップする事でコンパクトなバックアップにする事が出来る物と思われます。
ただ、Zabbix公式のドキュメントにはデータベースの中身の構造についての内容が見当たりません。
Database Schemas – Zabbix.org
https://www.zabbix.org/wiki/Database_Schemas
真偽不明な情報としては上記がZabbix 2.4のER図になります。これを参考にZabbix 3.0.10をインストールした状態のDBと見比べてみると、いくつかのテーブルで追加カラムが有る他、以下のテーブルが増えています。
結構な数のテーブルが増えていますが、いずれも設定系のテーブルであり、ログ系のテーブルではないものと思われます。つまり以下のようなmysqldumpコマンドを投げれば設定のみをバックアップする事が出来る物と思われます。
mysqldump -u [ユーザー名] -p –single-transaction –hex-blob \
–ignore-table=[DB名].alerts \
–ignore-table=[DB名].history \
–ignore-table=[DB名].history_uint \
–ignore-table=[DB名].history_str \
–ignore-table=[DB名].history_text \
–ignore-table=[DB名].history_log \
–ignore-table=[DB名].trends_uint \
–ignore-table=[DB名].trends \
–ignore-table=[DB名].auditlog \
–ignore-table=[DB名].auditlog_details \
–ignore-table=[DB名].events [DB名] | gzip > [ファイル名].gz
バイナリデータ（中身は画像）を含んだテーブルが有るので –hex-blob を付けておいてください。また、ファイル名は取得時刻が秒単位で分かるようにしておいた方がいいでしょう（後述）。
例: zabbix_configuration_only_backup_20170817_151515.sql.gz
上記コマンドで取得したダンプデータですが、まっさらなZabbixに設定を投入するなら良いのですが、例えばZabbix画面上で設定変更を色々と行い、元に戻したいといった用途に使用しようとすると、ログに残ったアイテムIDなどでつじつまが合わなくなってくる可能性が有ります。安全を期すためには「itemid」カラムのあるテーブルに注意する必要が有ります。
データが欠けても良いのであれば、バックアップを取った時点以降のログデータを吹き飛ばすのが一番簡単だと思います。clockカラムにUNIXタイムの形式で日付が入っているので、それ以降のデータを飛ばします。
DELETE FROM alerts WHERE clock >= [UNIX時間];
DELETE FROM events WHERE clock >= [UNIX時間];
DELETE FROM history WHERE clock >= [UNIX時間];
DELETE FROM history_uint WHERE clock >= [UNIX時間];
DELETE FROM history_str WHERE clock >= [UNIX時間];
DELETE FROM history_text WHERE clock >= [UNIX時間];
DELETE FROM history_log WHERE clock >= [UNIX時間];
DELETE FROM trends_uint WHERE clock >= [UNIX時間];
DELETE FROM trends WHERE clock >= [UNIX時間];
DELETE audit_d FROM auditlog_details AS audit_d
LEFT JOIN auditlog USING(auditid)
WHERE auditlog.clock >= [UNIX時間];
DELETE FROM auditlog WHERE clock >= [UNIX時間]
auditlog_detailsはauditlogに関連しており、単体ではclockカラムを持っていないのでdetailsの方を先にDELETEする必要が有ります。これらDELETE分をzabbix-serverが停止した状態で実行し、その後バックアップのダンプデータをDBに流し込みます。
あくまでDBのテーブルのカラム名などから推測してバックアップをしているので、この方法には何かしら不具合が含まれる可能性が有ります。非公式なバックアップ方法なので、自己責任でのご利用の程お願いします。
また、あくまでZabbix 3.0.10時点でのテーブル内容を参考にしているので、3.2等ではそのまま動かない事も有るかと思います。
なお、Zabbixの有償サポートに入っているユーザーであれば、公式で（おそらくより高機能な）設定のみのバックアップと復元が可能なようです。整合性をチェックをするような記載も有るので、この方法のようにデータを飛ばす必要も無いのかもしれません。ミッションクリティカルな用途で使うなら、サポートの有るツールを使った方がいいでしょう。
Zabbix設定バックアップツール | Zabbix Enterprise
http://enterprise.zabbix.co.jp/solutions/3661
PHPで動くCLIインタフェースの様な物を作りました。
https://github.com/lf-uraku-yuki/zabbix_db_config_backup