「メイド・イン・ヘブン」スキン適用中

Cocoonフォーラム

サイト内検索
書き込みの前に以下の3点をご確認ください。
  1. 1つのトピックにつき1つの質問を書き込んでください
  2. 不具合・カスタマイズ対象ページのURLを提示高速化を無効にしてください
  3. 該当部分のキャプチャ・環境情報とともに書き込んでいただけると助かります

何を書き込んだら良いか分からない場合は、以下のテンプレートをコピペしてご利用ください。

不具合・カスタマイズ対象ページのURL:

相談内容:

不具合の発生手順:

解決のために試したこと:

※文字だけでは正しく伝わらない可能性があるため、スクショ画像の添付もお願いします。
※高速化設定をしている場合は無効にしてください。
環境情報:

※↑こちらに「Cocoon設定 → テーマ情報」にある「環境情報」を貼り付けてください。

環境情報の取得方法はこちら。
https://wp-cocoon.com/theme-report/
高速化設定を無効にするにはこちら。
https://wp-cocoon.com/theme-trouble/

フォーラム利用ガイドリンク

  1. フォーラムガイドライン
  2. よくある質問と答え(FAQ)
  3. サポート対象外のケース
  4. 原因不明の不具合用トラブルシューティング
  5. トピックにHTMLを貼り付ける方法(推奨ツール:notepad.pw
  6. 真っ白画面でのエラーメッセージの確認方法
  7. ブラウザ環境チェックツール
  8. Cocoonカスタマイズ依頼

フォーラム質問後、問題等が解決した場合は結果を書き込んでいただけると幸いです。同様の問題で調べている方には、結果が一番気になる部分となります。

CONOHA WINGにてデータベース...
 
共有:
通知
すべてクリア

[解決済] CONOHA WINGにてデータベースがいっぱいになったときの対処方法について

42 投稿
4 ユーザー
37 Reactions
325 表示
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

こんにちは。

「Cocoonのことに限らず、WordPress以外でも何でも。単なる雑談用のフォーラムなので、気軽に書き込んでください」とのことなので・・「CONOHAWINGにてデータベースがいっぱいになったときの対処方法について」質問させてください。

 

CONOHAWINGを契約してサイトを運営しています。

最近データベース容量が以下の状態になりました。

5123.55MB/5120MB(容量一杯使ってます・・という状況)

これにより、記事が追加できない状況となりました(当然です)。

 

CONOHAはデータベースの生成は無制限なので、新にデータベースを生成して、入れ替えようとしたらWordpressのインストールの手順から始まり、一から始めなくてはならないのか・・?という状況です。

ここで知りたいことは

「データベース容量が一杯になったときに、Wordpressの設定を変更しないまま新たなデータベースへ変更することは可能でしょうか。また新たなデータベースに変更した場合に過去の記事は閲覧できなくなるでしょうか」

文章が下手なので意味が分からない場合は申し訳ございません。

よろしくお願いいたします。

 

This topic was modified 1か月前 by SHION_SHION

   
トピックタグ
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

投稿者:: @shion_shion

最近データベース容量が以下の状態になりました。

5123.55MB/5120MB(容量一杯使ってます・・という状況)

データベース容量ががこんなに多くなる理由はなんでしょう?

私のサイトは5,000以上投稿がありますが、100MBくらいしか、使用していないです。

投稿者:: @shion_shion

「データベース容量が一杯になったときに、Wordpressの設定を変更しないまま新たなデータベースへ変更することは可能でしょうか。

データベースの接続先を変更すれば、できると思います。

(設定を変えているとは言えるかもしれないですが)

投稿者:: @shion_shion

新たなデータベースに変更した場合に過去の記事は閲覧できなくなるでしょうか

新しいデータベースということは、以前のものは格納されていないということになろうかと思います。

 

複数のデータベースを読み込むことが、できるものなのか・・・。

有識者の方ならご存じかも?

 

最初に書きましたが、なぜデータベース容量がそんなに多くなるのかは、気になりますね。

 


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

MK2さん、ご返信ありがとうござます。

データベース容量ががこんなに多くなる理由はなんでしょう?

私のサイトは5,000以上投稿がありますが、100MBくらいしか、使用していないです

1万記事程度ですが、満タンです。。

データベースの接続先を変更すれば、できると思います。

(設定を変えているとは言えるかもしれないですが)

DBの接続先を変更したらやはりWPの設定を初期状態からやることになります。これがツライです。

新しいデータベースということは、以前のものは格納されていないということになろうかと思います

ということは、閲覧できないということですね。了解です。

最初に書きましたが、なぜデータベース容量がそんなに多くなるのかは、気になりますね

画像が多いからでしょうか。。もしくはWPの設定やプラグインの問題でしょうか。

ちょっと私、CONOHAに問い合わせてみます。でもCONOHAって対応よろしくないんですよね。。

 

 

 


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

投稿者:: @shion_shion

DBの接続先を変更したらやはりWPの設定を初期状態からやることになります。これがツライです。

元々の情報を控えておけば、もしくはコピー・アップロードすればできる言えばできますけれど。
しかし、それが根本的な解決になるとは思えないです。

投稿者:: @shion_shion

画像が多いからでしょうか。。もしくはWPの設定やプラグインの問題でしょうか。

画像そのものは、データベースには保存されません。
画像そのものは、サーバーにファイルとして保存されます。

WordPressで管理するために、画像の情報がデータベースに保存されますが、所詮はテキストデータです。
(メディアライブラリに表示されるためには、データベースに情報登録が必要です)

とても、そんなに肥大する原因とは思えないです。
(プラグイン等の設定にしても、テキストデータですよね)

例えば、wp-postsには、以下のような情報が登録されますが、所詮はテキストデータでしかないです。
(以下のデータをSQLファイルとしてエクスポートしてみましたが、759Bytesでした)

 
wp-postmataにも登録はされると思いますが、やはりテキストデータですし。
 
ちなみに、私のサイトには画像は3~4万枚(サムネイルを除く)ありますが、それであれくらいです。
(35,000枚くらいから数えていません。データベースは100MBくらいで、サーバー側は5GB以上あります。)
 
データベース容量がいっぱいになってしまう原因は、少なくともしっておいた方が良さそうには思うんですよね。
(サイト構成や使い方によって違うのかもしれないですが、少し異常な容量な印象を受けてしまいます)

   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

 mk2さん。ご説明ありがとうございます。画像そのものはサーバーにファイルなんですね。

データベース内容の内訳を掴む方法がピンとこないところで・・・

確かに肥大化してる原因が知りたいです。個人的に調べても現状掴めません。

最初から提示していればよかったのですが、以下の情報からなにかわかりますでしょうか。

ーーーーーーーーーーーーーーーーーーーーーーーーーー

----------------------------------------------
サイト名:東京トレンドニュース速報
サイトURL: https://tokyotrendnews2023.com
ホームURL: https://tokyotrendnews2023.com
コンテンツURL:/wp-content
インクルードURL:/wp-includes/
テンプレートURL:/wp-content/themes/cocoon-master
スタイルシートURL:/wp-content/themes/cocoon-master
親テーマスタイル:/wp-content/themes/cocoon-master/style.css
WordPressバージョン:6.5.2
PHPバージョン:8.2.15
ブラウザ:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Edg/124.0.0.0
サーバーソフト:Apache
サーバープロトコル:HTTP/1.0
エンコーディング:none
言語:ja,en-US;q=0.9,en;q=0.8,en-GB;q=0.7
----------------------------------------------
テーマ名:Cocoon
バージョン:2.7.2.6
カテゴリー数:249
タグ数:3589
ユーザー数:2
----------------------------------------------
Gutenberg:1
Font Awesome:4
Auto Post Thumbnail:1
Retina:0
ホームイメージ:/wp-content/uploads/2023/12/TOP_Image-Enhancer-scaled.jpg
----------------------------------------------
ブラウザキャッシュ有効化:0
HTML縮小化:0
CSS縮小化:0
JavaScript縮小化:0
Lazy Load:0
----------------------------------------------
利用中のプラグイン:
Advanced Ads 1.52.1
BlueskyTimeline for Wordpress 0.1.4
ConoHa WING コントロールパネルプラグイン 1.2
ConoHa WING 自動キャッシュクリア 1.0.0
SEO SIMPLE PACK 3.2.1
WP-Optimize - Clean, Compress, Cache 3.3.2
WP Headers And Footers 2.2.0
----------------------------------------------

 

 


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

データベースは、外部からは確認のしようがありません。
そのため、申し訳ないですが、まったく分からないです。

プラグインは少ない方のように思います。

 

データベースは、「phpMyAdmin」のようなツールを使わないとアクセスできないです。

テーブルの中身を見て、これは本来あるべきものなのか、それとも必要のないのに増えているのか、など判断が必要な気はします。

ちなみに、以下のプラグインをご利用のようですね。

投稿者:: @shion_shion

WP-Optimize - Clean, Compress, Cache 3.3.2

この管理画面で、テーブル別の容量は確認ができると思います。
異常に大きなテーブルがないか確認してみると、手掛かりにはなるかもしれません。
(ただ、詳細はテーブルの中身を見ないと分からないと思います)

データベースを触る際などは、事前にバックアップを取っておくことをお勧めします。
(何かあっても戻せるように。誤操作などで削除や更新などをしないか、注意は必要だと思います。)

 

ちなみに「WordPress データベース 肥大化」で検索すると、いくつかヒットします。
原因は人それぞれかと思いますが、参考にはなるかもしれないです。

あくまでも事例のご参考ということで、リンクしておきます。
(他にもいろいろヒットしますので、調べてみてください)

えっ!830MB!?WordPressのデータベースがめちゃくちゃ肥大していた件
https://www.taracohouse.com/blog/web/wp-database/

ワードプレスドクター 依頼事例:データベースの肥大化の解消
https://wp-doctor.jp/blog/2023/10/12/%E3%83%AF%E3%83%BC%E3%83%89%E3%83%97%E3%83%AC%E3%82%B9%E3%83%89%E3%82%AF%E3%82%BF%E3%83%BC-%E4%BE%9D%E9%A0%BC%E4%BA%8B%E4%BE%8B%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE-2/


   
chu-ya
(@chu-ya)
Famed Member Registered
結合: 2年前
投稿: 2325
 

@shion_shion さん

phpMyAdminで、DBの各テーブルの使用状態を、確認してみて下さい。

https://wp-cocoon.com/community/postid/77522/

上記の事もあり、以下のテーブルが肥大していると言う事はないでしょうか?

  • wp_cocoon_accesses
  • wp_options

   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 さん、ありがとうございます。

phpMyAdminで内容を確認してみます。バックアップも実施済です。

進捗があれば共有させてください!


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

各テーブルのサイズ(容量)だけであれば、以下プラグインで確認ができます。

投稿者:: @shion_shion

WP-Optimize - Clean, Compress, Cache 3.3.2

大抵は100MB未満におさまると思います。(環境によって違うかもしれないですけど)

それを超えるようなサイズのテーブルがあれば、怪しいです。


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@chu-ya さん、ご無沙汰しております。

コメントありがとうございます!!!

phpMyAdminで、DBの各テーブルの使用状態を確認してみました。

(確認方法がこれで正しいか不安ですが、PDFでデータをアップしました)

  • wp_cocoon_accesses
  • wp_options

ともに肥大しているように見えます。これが原因でしょうか。

This post was modified 1か月前 by SHION_SHION

   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

このPDFは危険です、削除してください。

外部から、データベースへのアクセスを許してしまう可能性があります。
(phpMyAdmin経由での各テーブルへのリンクが埋め込まれています。)

私から、phpMyAdminが開けます。
(アドレスが、ConoHaのデータベースサーバーみたいです。)


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 速攻で消しました。

ご助言ありがとうございます。


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

間にあったみたいですね。
良かったです。

ログイン画面を突破すれば、外部から直接データベースの操作が可能な状態でした。
ビックリしてしまいました。


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@chu-ya さん

@MK2 さん

各テーブルのサイズ(容量)を確認しました。

wp_posts、wp_postmetaが肥大化しています。

(Postieというプラグインを使ってメールで大量の記事を生成しておりました。)

これがあやしくないでしょうか。


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

「wp-posts」の3.66GBは突出して多いですし、異常と言える気はしますね。


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 だれも止めなければ明日消しますこのデカイやつ・・


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

「wp-posts」には、いろんなものが保存されています。

投稿ページや固定ページの中身は、「wp-posts」に保存されます。
(編集画面で、「下書き保存」や「公開」「更新」したものは、「wp-posts」に保存されます。以前書いた、画像の情報も)


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

念のため、お伺いします。

リビジョンは溜まっていないですよね。
WP-Optimize で、リビジョンのレコード数は確認できます。)

そうはいえ、とてもリビジョンごときで、こんな容量になるとは思えないですけれど、念のためです。


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 では・・消すわけにはならないファイルなんですね。


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 すべての投稿リビジョンをクリーンにて以前クリアしているので

現在はない状況です。。

 


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

データベースですので、ファイルとは呼びません。

「wp-posts」のようなものは、テーブルと呼びます。(レコードを格納するための器)

この中に、たくさんのレコードが入っています。

 

やはりリビジョンではないですよね。

今回の件は、この中のレコードの中身を確認をして、何が増えているのか確認する必要がありそうです。

phpMyAdminで直接閲覧するか、エクスポートしてから確認するか。

いずれにせよ、データベースを触ることになりますので、注意が必要です。


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

ちなみに、以下で全部でしょうか。

投稿者:: @shion_shion

 

使用量は以下のことですので・・・。

投稿者:: @shion_shion

5123.55MB/5120MB(容量一杯使ってます・・という状況)

wp-postsが3.66GBだとすると、まだ他にもありそうな感じが。

wp-postsとwp-optionsのオーバーヘッドが、881MBと361MBと大きいですから、これを足すと1.2GBくらい。
そうすると、計算はあいそうな気はしますね。
(wp-optionsは、本体のサイズに対して、オーバーヘッドの方がかなり大きいです)

テーブル内のレコードの確認は、知識がないと難しいかもしれないです。
(ご存知でない、調べながらできない、そういう場合は、プロにお願いする必要があるかもです)


   
わいひら
(@yhira)
Illustrious Memberサイト Admin
結合: 6年前
投稿: 16568
 

MySQLのオーバーヘッドも結構なものですね。
こちらの方法で最適化を行なうと881MB分空くのかな。wp_optionsもオーバーヘッドが大きいので、これも最適化した方が良いのかも。
https://webkaru.net/mysql/phpmyadmin-optimize-database/
phpMyAdminの昨日使ったものなので、大丈夫とは思いますが、絶対は保証できません。事前にバックアップを取って元に戻せる体制を整えておく必要はあると思います。あくまで自己責任になりますので事前にご了承いただければ幸いです。
自信がない場合は、プロに依頼することを考えるのもありかもしれません。

ConoHa WINGは自動バックアップ・リストア機能があるので、これで戻す方法はあると思います。
https://webkaru.net/mysql/phpmyadmin-optimize-database/
※戻せても1日前とかになると思います。

※mk2さんさんと書き込み内容がかぶってしまったようです。

This post was modified 1か月前 5回 by わいひら

   
SHION_SHION reacted
わいひら
(@yhira)
Illustrious Memberサイト Admin
結合: 6年前
投稿: 16568
 

投稿者:: @shion_shion

1万記事程度ですが、満タンです。。

3.66GBはかなりのものですね。1記事あたり本文はだいたい何文字ぐらいでしょうか?

This post was modified 1か月前 by わいひら

   
SHION_SHION reacted
わいひら
(@yhira)
Illustrious Memberサイト Admin
結合: 6年前
投稿: 16568
 

phpMyAdminでwp_postsの構造はどのようになっていますか?スクリーンショットを頂ければ幸いです。
一般的なwp_postsの構造はような感じです。

This post was modified 1か月前 by わいひら

   
SHION_SHION reacted
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

ちょっと私の環境で確認したのですけれど。

WP-Optimize」で、「wp-posts」のレコード数の確認ができますが、ちょと違和感のある数字でした。
(5,000レコード台)

そこで、「phpMyAdmin」で、同じく「wp-posts」のレコード数を確認すると、2倍くらいの数字でした。
(10,000レコード台)
「phpMyAdmin」のレコード数は、しっくりくる数字なんですよね。

データサイズは両方とも差異はほぼ無い感じでした。

「WP-Optimize」のレコード数は、何を表示しているのでしょう?

レコード数に関しては、「phpMyAdmin」で確認した方が良いような感じがします。
(誤操作には気をつけてください)

もしかすると、もっとレコード数が多いのかもしれないです。
(私の環境と同様の状態が発生していれば)


   
SHION_SHION reacted
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 

ちなみに、以下で全部でしょうか。

DBをいじっていたら壊れてしまって3日前のDBをバックアップから取り込みました。

その内容を添付します。

テーブル内のレコードの確認は、知識がないと難しいかもしれないです。
(ご存知でない、調べながらできない、そういう場合は、プロにお願いする必要があるかもです)

たしかに難しかったですが、こういう壁を乗り越えて知識が付くと思いがんばります!!!


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

投稿者:: @shion_shion

DBをいじっていたら壊れてしまって3日前のDBをバックアップから取り込みました。

気をつけましょう、本当に。

 

添付いただいた画像は貼り付けさせていただきますね。

 
 
3日前とのことですけれど。
 
以前添付いただいたものと比較すると・・・。
 
「wp-posts」が、3.66GB ⇒ 4.32GBと、僅か数日で600MB以上変化があります。
レコード数は、41,924件 ⇒ 63,292件と、21,000件以上変化があります。
(このプラグインのレコード数を信用して良いのかはありますけれど)
 
ちょっと尋常ではないと思います。
(人間の手で、こんなレコード数を追加ができるものなのか・・・)

   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@yhira アドバイスありがとうございます。

MySQLのオーバーヘッドも結構なものですね。
こちらの方法で最適化を行なうと881MB分空くのかな。wp_optionsもオーバーヘッドが大きいので、これも最適化した方が良いのかも。
https://webkaru.net/mysql/phpmyadmin-optimize-database/

添付のようにオーバーヘッドの項目がないので「行」に数値があるのもを最適化いたしましたが、

最適化前後のオーバーヘッド容量に変化がございませんでした。

 

 

 


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 

これは

ゴミ箱にあった6000記事程度を削除した結果、このように容量が増えました。

たしかにこの6000記事を削除したとたんに容量が増えました。

削除しないでおいておくのも気持ち悪いですが、そのままにした方がいいのでしょうか。。

 


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

ああ、3日前ということは、時系列で言えば・・・。

容量は、4.32GB ⇒ 3.66GB
レコード数は、63,292件 ⇒ 41,924件

ゴミ箱のものを削除した結果、上記のように変化したということですね。

ゴミ箱のものは、再利用することがないのであれば、削除して問題いなと思います。
むしろ、6,000件もあれば、容量圧迫の原因になると思います。
(6,000件、それぞれにリビジョンが3~4件あれば、万単位レコードは減るのかも?)


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

もしかして、私変なこと言っていますか?

一度、時系列にご説明いただくと助かります。

できるだけ主語を省かず丁寧めだと助かります。(私は察しが悪いもので)


   
SHION_SHION reacted
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

 

mk2さん、chu-yaさん、わいひらさん

今回の問題にコメントをいただきありがとうございます。
以前からトラブルが解決できないときにはこちらのフォーラムに救われております。

mk2さんは変なこと言ってません!!!
私がちょっといっぱいいっぱいなので、フリーズしておりました。
(途中いただいた質問にもわかる範囲で回答していきます)

 

みなさんのコメント内容から、色々試していたらよい進捗がありました!

結論からお伝えすると、

①3日前のDBのバックアップデータで復元

(現状容量がフルだったので、少し空きのある過去の状態に戻した)

②phpMyAdminのクリーニング、WP-Optimizeでのクリーニング

 

これでDBの容量が「1603MB/5120MB」となりました!!!!!!!!!!!

DBの容量がフルだと、様々な処置も上手くいかないのではないか・・・と思っております。

 

今までの流れをここ記載したいのですが、画像を入れる方法がわからず添付ファイルにまとめました。

 

解決と言ってもよいのではないでしょうか。

なぜDBの容量が増えたのかは不明瞭ですが、、、、

 

 

 

 

 

 

 

 

 

 


   
わいひら
(@yhira)
Illustrious Memberサイト Admin
結合: 6年前
投稿: 16568
 

 docxの内容を貼り付けておきます。
以下転載します。

--------------------------------

mk2さん、chu-yaさん、わいひらさん

今回の問題にコメントをいただきありがとうございます。
以前からトラブルが解決できないときにはこちらのフォーラムに救われております。

みなさんのコメント内容を見返して、よい進捗があったので時系列含めてご報告します!

mk2さんは変なこと言ってません!!!
私がちょっといっぱいいっぱいなので、フリーズしておりました。
(途中いただいた質問にもわかる範囲で回答していきます)

 

 

――――――――――――――――――――――――――――――――――――

■04/21

CONOHAWINGで運営しているサイトのDBがいっぱいになって記事が追加できない状況になる。5123.55MB/5120MB(容量一杯使ってます・・という状況)

データベース容量ががこんなに多くなることが異常で理由が不明。

サイトの記事数は「1万弱」、ひとつの記事の文字数ははざっくり平均5万文字程度。

――――――――――――――――――――――――――――――――――――

※主にテキストデータでるのにここまで容量が増える理由は把握しておく必要性がある。

 

 

――――――――――――――――――――――――――――――――――――

■4/22 

データベースは、「phpMyAdmin」のようなツールを使わないとアクセスできない

ことを知る。テーブルの中身を見て不要なものを判断する必要があるかも。

(ちゃんとバックアップとってから!☞CONOHAは自動バックアップなのでOK)

 

個人的に調べたら、このプラグインでDBをクリーンにできるのではないか

WP-Optimize - Clean, Compress, Cache 3.3.2

「データベーステーブルの最適化」と「すべての投稿リビジョンをクリーンを実施」するも

データサイズ、オーバーヘッドのボリュームに変化なし。

 

ワードプレスドクター 依頼事例:データベースの肥大化の解消

えっ!830MB!?WordPressのデータベースがめちゃくちゃ肥大していた件

など事例をいただくがちょっとわたしにどって手を付けづらく内容のみ確認。

 

phpMyAdminで、DBの各テーブルの使用状態を、確認

wp_postmetawp_postswp_optionsなどが大きい(行でしかサイズを確認できない??)。

 

 

各テーブルのサイズ(容量)だけであれば、プラグインで確認ができるので

確認してみた。

WP-Optimize - Clean, Compress, Cache 3.3.2

 

「wp-posts」には、いろんなものが保存されています。

投稿ページや固定ページの中身は、「wp-posts」に保存されます。
(編集画面で、「下書き保存」や「公開」「更新」したものは、「wp-posts」に保存されます。以前書いた、画像の情報も)だから消してはいけない!

また、リビジョンも溜まってない。

phpMyAdminで直接閲データベースを触る決心が固まる。

――――――――――――――――――――――――――――――――――――

■04/23

MySQLのオーバーヘッドも結構なものなので、
こちらの方法で最適化を行なう。
https://webkaru.net/mysql/phpmyadmin-optimize-database/

☞この方法ですが、DBの内容をいじって壊した後に、バックアップから復旧させた後に

もう一度実施したら効果がでました。後ほど記載します。

※わいひらさんからのご質問

3.66GBはかなりのものですね。1記事あたり本文はだいたい何文字ぐらいでしょうか?

☞おおよそ5万文字程度です。少ない文字数から10万文字程度のものまで様々です。

 

phpMyAdminでwp_postsの構造はどのようになっていますか?スクリーンショットを頂ければ幸いです。

 

わいひらさん、こちらになります。

 

MK2さんから

WP-OptimizeとphpMyAdminでのレコード数に違和感があるとコメントをいただく。

 

わたしのDBで確認、wp_postsで比較すると

 

WP-Optimize:36,270

phpMyAdmin:38,092

 

レコード数に関しては、「phpMyAdmin」で確認するようにします。

 

また、BDをバックアップから復帰させた際に「wp-posts」が、3.66GB ⇒ 4.32GBと、僅か数日で600MB以上変化があった。これはゴミ箱にあった不要な記事6000件を削除したことが原因。(BDをバックアップから復帰させた後のCONOHA管理画面でのDB容量の4720.2MB/5120MB)

 

――――――――――――――――――――――――――――――――――――

■04/24

BDをバックアップから復帰させた状態でクリーンの処置(phpMyAdminのクリーン、WP-Optimizeでのクリーニング)をしたら、以下の変化がありました。

 

  1. WP-Optimizeでの状況
  2. phpMyAdminでの状況

 

  • CONOHA管理画面でのDB容量は変化あり!!! 2MB/5120MB

現在は③の状態となっており、だいぶ容量が削減できております。

結果、3日前のDBのバックアアップから、各種クリーニングを実施して削減できました!!!


   
わいひら
(@yhira)
Illustrious Memberサイト Admin
結合: 6年前
投稿: 16568
 

投稿者:: @yhira

☞おおよそ5万文字程度です。少ない文字数から10万文字程度のものまで様々です。

この文字数だったら、リビジョンとかも含めるとそれだけデータベースが肥大化するのは、納得できるかも。

投稿者:: @yhira

わいひらさん、こちらになります。

これは上のメニューが「表示」になっているので、「構造」ではないようです。
「構造」は以下のスクリーンショットの赤枠部分です。

投稿者:: @yhira

一般的なwp_postsの構造はような感じです。

問題が解決したっぽいので必要はなさそうですけど。

This post was modified 1か月前 by わいひら

   
わいひら
(@yhira)
Illustrious Memberサイト Admin
結合: 6年前
投稿: 16568
 

投稿者:: @shion_shion

②phpMyAdminのクリーニング、WP-Optimizeでのクリーニング

phpMyAdminのクリーニングってなんだろう。最適化とまた違うものなんでしょうか?


   
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

投稿者:: @shion_shion

投稿者:: @shion_shion

②phpMyAdminのクリーニング、WP-Optimizeでのクリーニング

phpMyAdminのクリーニングってなんだろう。最適化とまた違うものなんでしょうか?

「WP-Optimizeでのクリーニング」も同様ですね。
最適化はあると思うのですけれど、


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@yhira クリーニングではなく「最適化」でした。正確に記載してなくて申し訳ございません(うれしくて浮かれてました・・・)


   
わいひら reacted
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 こちらもクリーニングではなく「最適化」でした。正確に記載してなくて申し訳ございません(うれしくて浮かれてました・・・)


   
mk2 reacted
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

どちらも「最適化」をなさったということですね。

ゴミがたくさん溜まっていた感じみたいですね。


   
SHION_SHION
(@shion_shion)
Eminent Member Registered
結合: 4か月前
投稿: 34
Topic starter  

@mk2_mk2 そうなんです。ただ、DBが満タンのままでは最適化が正常にいかないのではないでしょうか(憶測ですが・・)。今後は適時最適化を実施していきます!

コメントをいただいた方々、本当にありがとうございました!!!


   
わいひら reacted
mk2
(@mk2_mk2)
Illustrious Member Moderator
結合: 3年前
投稿: 7101
 

SHION_SHIONさん

投稿者:: @shion_shion

DBが満タンのままでは最適化が正常にいかないのではないでしょうか

空き領域がないのに、最適化はできないと思います。

昔は使っていたけれど、今はデータ削除された領域があれば、最適化をすれば開放されると思います。
その他にも、領域の再配置など行われて、断片化されたデータが整理されるイメージではないかと思います。

WordPressのゴミ箱に入っている状態は、まだデータは生きていますから、開放のしようもないと思います。

 

ちなみに、このトピックは「解決済」でよろしいのでしょうか?
(当方にて「解決済」にさせていただきました。もしそうでないならば、解除していただいてもOKです)


   
わいひら reacted
共有:

問題の解決に至った場合には、トピック冒頭の「解決済み」をクリックしていただけますと幸いです。

また、有用な回答があった場合は返信右下にある「いいね!」もご活用ください。回答者の励みになります。

「いいね!」機能はフォーラム登録者のみが利用できる機能です。

CC BY-ND 2.1)準じていれば(リンクを貼っていただければ)転載も自由です。カスタマイズ記事を書く際にコード等をコピペ利用していただいて構いません。

フォーラムの使い方がよくわからない場合は、テストトピックで自由にテストしていただいて構いません。

最近の書き込みはこちら。

詳細なカスタマイズ依頼をするならこちら。

タイトルとURLをコピーしました