[B! mysqldump] a2ikmのブックマーク

長年の議論に終止符 -- MySQL/MariaDBのバックアップとロックの関係＋クラッシュセーフについて - interdb’s diary

よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。オンラインバックアップに関するロックの正確な記述より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。ロックの必要

a2ikm 2016/09/05

リンク

Percona XtraBackupの抽出と圧縮の並列処理 | 外道父の匠

久々にXtraBackupの話題です。以前に紹介した基本手順では、tarアーカイブをgzip圧縮していました。実はこれよりもっと速い方法がありまして、データサイズが大きくなると必須になってくるのではないかと思います。その、計測内容と結果について紹介していきたいと思います。リンク本件に関係ありそうなドキュメントのリンクになります。 The xtrabackup Option Reference Streaming and Compressing Backups The xbstream Binary Accelerating with –parallel copy and –compress-threads Making a Compressed Backup (qpress) 本家ブログのベンチマークもあります。 Compression for InnoDB backup – My

a2ikm 2015/10/14

リンク

パーティションごとにmysqldumpする - しるてく

ログテーブルのようなすごい巨大なテーブルがあって、古いログはいらないから削除したい、でも万が一のときにデータはどこかに取っておきたいというときは、 --complete-insert カラム名を含んだ、完全なINSERTステートメントを使用 --no-create-info ダンプされたテーブルを再作成するCREATE TABLEステートメントを書かない --where WHERE状態に選択された行のみダンプこのあたりをオプションに含めて置くとよいのかなーと思った。 # mysqldump -u$user -p \ > --default-character-set=utf8 \ > --complete-insert \ > --no-create-info \ > --where="created_at>='2012-04-01 00:00:00' and created_at<'2

a2ikm 2015/08/11

リンク

Percona XtraBackupの基本的な使い方 | 外道父の匠

PerconaといえばXtraBackup!! といっても過言ではないこの機能。バックアップ手法はいくつかあれど、少なくともmysqldumpを使うくらいならXtraBackupを使っとけばいいと思います。手始めに、簡単な使い方から紹介していきます。はじめにインストールについては前にまとめてあり、単にパッケージインストールするだけになっています。バージョンは必ず最新を使ってください。だいぶ安定してきたとはいえ、バグフィックスは常にされており、特に v2.0.0 では8GBを超えるデータの際にエラーが起こるため、修正されています（参照：Announcing Percona XtraBackup 2.0.1）。 XtraBackupはmysqldumpと比べると、バックアップ作成速度が遅くなったり、データ容量が大きくなったりする場合がありますが、その代わりに以下のようなメリットがありま

a2ikm 2015/06/26

リンク

mysqldump --dump-slave について - Studio3104::BLOG.new

MySQL5.5から追加になった、--dump-slaveオプションをつけてmysqldumpを実行すると、バックアップの最中Slave_SQL_Threadが停止してしまう。これでは、--single-transactionオプションのメリットが大きく削がれてしまうことになる。 mysqluftに参加させていただいたときに、@nippondanjiさんにこのことについて相談したところ、バグ登録され、そのついでにパッチが書かれるという超俺得な出来事があった。「FLUSH TABLES WITH READ LOCKしてないじゃん」という内容だが、Slave_SQL_Threadが停止してしまう問題についても一緒に対応してくださった模様。 @nippondanjiさんありがとうございました。 MySQL Bugs: #65035: FLUSH TABLES is missing on my

a2ikm 2015/06/24

リンク

[MySQL] ibdata1のサイズを削減する手順 [InnoDB] | oshiire*BLOG

我が家では”Zabbix“や”WordPress“を利用していて、そのバックエンドのDBとして、”MySQL“を利用しています。立ち上げに特に設計もしているわけでもなく、何となく使い始めたために、知らぬ間にいろいろと課題が出てきました。稼働に影響を与えているものとして 2つあります。 MySQLのdatadir直下にある ibdata1がディスクそのものを圧迫している一つのサーバにいろいろと同居している上、SMPも使えず 32bitによるメモリ制限もあって、MySQLがボトルネックになっている何も考えずに作り始めるってのは、ホント問題ですねぇ。アーキテクトとしては最低です。まぁ、作り始めたころはまだアーキテクトではなかったので、良しとしましょう [I]よろしくないこの二つの課題の内、一つ目「ibdata1ファイルがディスクそのものを圧迫している」問題について、先にまず対処しました

a2ikm 2015/06/24

思い切りが大事

リンク

mysqldumpをgzipでバックアップとリストア · GitHub

Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address.

a2ikm 2015/06/23

リンク

RDSのデータをmysqldumpしてS3に保存する - (ﾟ∀ﾟ)o彡 sasata299's blog

2014年01月07日13:52 AWS Ruby RDSのデータをmysqldumpしてS3に保存する弊社ではデータを AWS の RDS を使って管理しています。バックアップは自動で取ってくれるんですが、RDS では残せるバックアップのスナップショット数が決まっているのでもう少し過去のバックアップも取りたい。気軽にバックアップを S3 に保存することは出来ないものか。追記：14:12 RDS のスナップショットを手動で取ったりすれば良いんですけど、アカウントが悪用されたりして全部消えちゃったら怖いなぁと。そういう背景もあって念のため S3 上にも置いておきたいなぁと思った次第です(＊ﾟ∀ﾟ) 追記：14:17 バックアップのスナップショット数増やすことも可能みたいですね。 @sasata299 あとAmazonに申請すればRDSのスナップショットの上限値を増やせるらしいので参考にど

a2ikm 2015/05/08

リンク

データサイズが大きいDBをmysqldumpする時 – OpenGroove

データサイズが大きいDBに対してオプションを指定せずにmysqldumpを実行するとメモリ使用率が100%になってしまい、OSがプロセスをkillし始める(Out Of Memory Killer)。これを回避するには、以下のいずれかをオプションとして指定する。 --quick --opt --single-transaction – -quickはクエリをバッファせずに直接ダンプするため、大量のダンプの際には特に有効。 – -optを使用すると以下のオプションを全て含めて実行することになるので、- -quick より有効なダンプファイルが作成できる、かも。 --quick --add-drop-table --add-locks --extended-insert --lock-talbes 追記：- -opt オプションはMySQL5.1以降はデフォルトで有効だそうだ。参考URL