はじめに mysqldumpコマンドで取得したダンプファイルから任意のテーブルのみリストアする方法を記載します。 データベース全体のバックアップはあるもののリストアしたいのは一部のテーブルのみといった場合に対応できます。 環境 CentOS 6.4 MySQL 5.1 ダンプファイルを分割する cspilt コマンドを使用します。
![MySQLのダンプファイルから任意のテーブルのみリストアする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/443d2350af4540c6994795aed5159ccdf11412c6/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9TXlTUUwlRTMlODElQUUlRTMlODMlODAlRTMlODMlQjMlRTMlODMlOTclRTMlODMlOTUlRTMlODIlQTElRTMlODIlQTQlRTMlODMlQUIlRTMlODElOEIlRTMlODIlODklRTQlQkIlQkIlRTYlODQlOEYlRTMlODElQUUlRTMlODMlODYlRTMlODMlQkMlRTMlODMlOTYlRTMlODMlQUIlRTMlODElQUUlRTMlODElQkYlRTMlODMlQUElRTMlODIlQjklRTMlODMlODglRTMlODIlQTIlRTMlODElOTklRTMlODIlOEImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTlmNjYwNmRiMDMzYTEyM2E4OWU0ZTQ5NTllZTUwOTEz%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwdG9zaGlybzMmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTRmOTFmODhhNzQ0YzlhODlhZDdjNDU1OGRhMzk5ZmI0%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D7585e4f27b722ed4486e6e075644703e)
photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった!さあランチタイムだ! ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
MySQL標準のダンプツールmysqldumpについて、基礎的な使い方からよく使われるオプション、特徴までを含む25個の問答集。 1) mysqldumpはテキストバックアップツール?それともバイナリバックアップツール? テキストバックアップツールだ。バックアップファイルを開けば、データベースとその中のオブジェクトを作り直すための全文が見られる。テーブルにデータを詰め込むためのinsert文ももちろん含まれている。 2) mysqldumpのコマンドラインオプションは? $ mysqldump -u [uname] -p[pass] –databases [dbname] [dbname2] > [backupfile.sql] 3) 全データベースのバックアップはどうしたらいい? $ mysqldump -u root -p –all-databases > backupfile.sql
データをちょっと取り出して実験したいときに、mysqldumpのSQLを編集するのが面倒だし、DELETEを書くのが面倒だった。 MySQLのテーブルの指定行を様々な形式で取り出したい。コマンドのみでMySQLのテーブルを取り出せる形式をまとめてみた コマンドで取り出せる形式は次の通り。 SQL HTMLテーブル XML テーブルの部分コピー これらであれば、簡単にテーブルをSQLとして取り出すことが出来る。 1:テーブルをHTMLのテーブルで取り出す。 mysqlコマンドで結果をHTMLに出力する。 よく見かける例なので有名かも。最近のSQLサーバーなら一般的にサポートされている。 形式 echo "ここがSQL" | mysql -p -u ユーザー名 DB名 -H -H --html 出力をHTMLテーブルにする。 実例 echo 'set names utf8;select * f
PerconaといえばXtraBackup!! といっても過言ではないこの機能。 バックアップ手法はいくつかあれど、少なくともmysqldumpを使うくらいならXtraBackupを使っとけばいいと思います。手始めに、簡単な使い方から紹介していきます。 はじめに インストールについては前にまとめてあり、単にパッケージインストールするだけになっています。 バージョンは必ず最新を使ってください。だいぶ安定してきたとはいえ、バグフィックスは常にされており、特に v2.0.0 では8GBを超えるデータの際にエラーが起こるため、修正されています(参照:Announcing Percona XtraBackup 2.0.1)。 XtraBackupはmysqldumpと比べると、バックアップ作成速度が遅くなったり、データ容量が大きくなったりする場合がありますが、その代わりに以下のようなメリットがありま
MySQLのデータベースをバックアップするときに、mysqldumpコマンドを使用します。 データベースの使用量が多くなるとダンプしたときに大きなファイルが当然できてしまいます。 18GBのデータベースをダンプすると13GBぐらいのダンプファイルができたりします。 13GBのデータも圧縮すると2.1GBぐらいになったりします。 scpで別のマシンにコピー・バックアップする場合にも13GBのファイルだと結構時間がかかるので、やはり圧縮してあるほうが望ましいです。 mysqldumpの出力をパイプでgzipコマンドに渡してしまえば、圧縮することが簡単にできます。テンポラリファイル・テンポラリの領域も必要ありません。 mysqldump -u root -p mydb | gzip > mydb.sql.gz 圧縮したmysqlのデータをmysqlにインポートするには、gunzipで展開した結果
プログレスバーを簡単に表示できる pv について説明する。 インストール方法 自分の環境(debian 6.0.3)だと aptでインストール出来る。RHEL系ならここかな。 使い方 端的に言うと、「cat + 標準エラー出力にプログレスバー」という動きを取る。 f440@abhoth[10]:~$ yes | pv >/dev/null 529MB 0:00:08 [67.2MB/s] [ <=> ] 8秒で合計529MB、秒間67.2MBくらいで「y」の文字が pv を通り抜けてるのがわかる。 -lオプションをつけると行モードになり、転送量ではなく転送行数を調べられる。 f440@abhoth[10]:~$ yes | pv -l >/dev/null 435k 0:00:10 [45.9k/s] [ <=> ] 10秒で435行、秒間45900行くらいが通り抜けてるのがわかる。 他に
よい機会なのでまとめておく。対象は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だけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く