テーブルクラッシュで改めて世にバックアップの重要性を身をもって訴えたMMRTでしたが、その後のバックアップに関しての報告です。
>hiromasa.another » WordPressのMySQLバックアップ
いつものようにひろまさ氏に知恵をお借りしています。
で、MMRT本家とこのブログを対象に実施しました。スケジュールとして、本家は週一でバックアップを実行し、このブログは毎日という設定です。
結果は本家はOK、このブログはダメ・・・。以下、失敗しているダンプファイル。
-- MySQL dump 10.13 -- -- Host: localhost Database: **** -- ------------------------------------------------------ -- Server version 5.1.22-rc /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
これがすべてです。(1KB) 見事に途中で仕事を放棄されてます。
この結果を考察し、改善案を出せ!と言われれば、(できるかできないかは別として)選択したテーブルのみをバックアップできないのか?という案しかないっすね。例の morphemeテーブル(約104MB)は切り捨て、もしどうにかなったらまた一から学習して頂くとして、コメントと記事関係だけでもバックアップできていたらうれしいんですけどねぇ。
現在は週一で手動バックアップを不定期に実施中であります。( ̄^ ̄)ゞ
# 1週間くらいならチョロいけど、1ヶ月の手動復旧はめんどくさかったので・・・
コメント
こんにちは〜!
やっぱりデータベース大きくて、負荷で落とされているんでしょうか。。
ちなみに、SSH から直接シェルたたくのってできましたかね?
mysqldump コマンドのオプションをみると、テーブル単位でもできるようです。
ご指摘の通りで、morpheme はなくても再生成可能なのでバックアップ不要ですね。
テーブルを WP 標準のみにしぼるようにちょっとやってみます。 :-)
まいどっす。
どうも、このs325サーバはできないっぽいです。(涙目
引っ越しも検討中であります。
なんと、それは朗報ですな。できたらうれしいです。ぼくも勉強してみることにしますです。
なるほど、なるほど。 高負荷シェルの cron 実行は、リソース制限かけている可能性は十分考えられますね〜。
テーブル指定は省略可能引数に [tables] があるので、データベース名($DATABASE)の後ろにテーブル名をかけばいけそうです。 table”s” なのでスペース区切りすれば複数テーブル指定できそうな雰囲気です。
どうもです。
ボクの方もバカなミスを1カ所発見したので
それを検証してから、それでもダメな場合は、テーブル指定を試してみたいと思います。
リンク先、参考になります。ありがとうございます。