まるむしアンテナ

自作に改造、修理、メンテナンス...とりあえずなんでも自分でやってみよう!

By

MySQL WordPressの投稿済み記事を一括修正するSQL

WordPressにかぎらず、DrupalなどDBを利用したブログシステムでは、投稿記事がテーブルに格納されている。
WORDPRESSの投稿記事の文中に定型文として挿入している文字を修正したい場合、
エクスポート/インポートでテキスト修正する方法もありますが、
件数が多すぎてエラーになったり、作業に時間がかかってしまったりで結構苦労します。
ところがこのようにSQL文で修正すると、作業はDB内で完結するのであっという間に終わりますよ。
wordpressの本文は、wp_posts というテーブルの post_content のカラムに格納されています。
UPDATE wp_posts SET post_content=REPLACE (post_content,’変更前文字列’,’変更後文字列’)

なお、ブログシステムを稼働させたままシステムデータを手動更新する事は
システムに矛盾を生じさせる原因につながります。
当然のことながらメンテナンスモードにしてから作業するとか、
失敗してもいいようにバックアップを取ってから作業するなどの配慮が必要ですよ。

By

Linux CentOS+PHP+MySQL phpMyAdminでファイルのインポートをすると「恐らくあまりに大きなファイルをアップロードしようとしました。」と表示される

Linux CentOS+PHP+MySQL phpMyAdminでファイルのインポートをすると「恐らくあまりに大きなファイルをアップロードしようとしました。」と表示される
いまインポートしようとしているファイルは、50Mだ。
インポートの指示画面を見ると確かに、(最大サイズ:2,048KB)と表示されている。
一見MySQLの設定のように思われるがそうではない。
phpMyAdminはPHPなので、phpの制限を受けているのだ。
ってことで
/etc/php.ini

upload_max_filesize = 2M

upload_max_filesize = 128M
に変更
apacheの影響下なのでサービスからhttpdを再起動。
?
最大サイズが、8Mに増えましたが128Mにはなっていません。
原因はこれですね。
post_max_size = 8M
これを変更します。
post_max_size = 128M

最大サイズが指定どおりに増えました。^^
ならば
post_max_size = 128M 
の設定だけでも今回の問題は解決するのか? 
upload_max_filesize = 2M
に戻してみると最大サイズは2Mに逆戻りです。
upload_max_filesizeが基本のようですね。
ということで、
/etc/php.ini
upload_max_filesize = 128M
post_max_size = 128M

で解決です。^^

By

CentOS+apache+MySQL Linuxサーバー MySQLサーバーの設定をチューニングする

CentOS+apache+MySQL Linuxサーバー MySQLサーバーの設定をチューニングする
ディスクIOの分散などを施したが、CPU負荷を表すCPU load averagesの値が以前高い値を示すまるむしサーバー。
残るはデータベースサーバー(MySQL)がかなり怪しい。
なんたって導入後一度もチューニングしていないのだ。
ということでとりあえず状態を確認するために、お手軽にphpMyAdmin(DB管理ツール)から様子を見てみることに。
phpMyAdmin
ツールからレポートを見るのは「MySQLのランタイム情報」だ。
問題があると思われる値は、赤い文字で示されている。
但し、すべてを鵜呑みにして赤字箇所を解消する必要があるということではない。
CMSツールなどを導入しているとこれらをすべて解消することはたぶん難しい。
チェックしなければならない箇所を絞り込んでくれているという見方のほうがいいかもしれない。
原因となっていそうな項目をピック。
key_buffer
table_cache
record_buffer
tmp_table_size
max_heap_table_size

様子を見ながら微調整と行きたいところだがとりあえずサックっと改善して効果を確かめたいので
ちょっと大きめに設定するような感じ値を適当に設定
key_buffer=512
table_cache=512
record_buffer=1M
tmp_table_size = 256M
max_heap_table_size=256M

設定値が結構いい線出しているのか、的外れなのかは使用環境によるので参考になるかは怪しいが、
同様の現象で困っているなら、まずチューニングすべき項目はこれらだ。
この設定を /etc/my.cnf に追記するし、設定を反映あるいはデータベースを再起動。
様子を見る….WEBサーバーにがんがんアクセスして負荷を掛けてみる...
おおぉぉいい感じ! 
CPU負荷を表すCPU load averages も0.02 だ。
少々の負荷でも1にはならない。実に健全だ。
FTPパラでファイルを転送させた状態で、更にWEB(wordpressなど)にアクセスをかけると
CPU load averagesは2.5ぐらいに上昇するが、処理を終了すればほどなく正常値に戻ってくれるようになった。
悪循環のスパイラルはもうない。
しかし雑なチューニングでこれほどまでに効果が出てしまうとは今までなんといいかげんな設定だったことか。^^;
ちなみにデータベースは快適に動作していますが、
「MySQLのランタイム情報」を見ると赤字項目はまだまだ残ったままです。
試しにキャッシュサイズなど言われるがままにどんどん大きくしてみましたが解消されることはありませんでした。
そんな単純なもんじゃないって事ですね。トータルバランスが大事です。

【送料無料】MySQLによる最速RDBMS構築ガイド

【送料無料】MySQLによる最速RDBMS構築ガイド
価格:3,570円(税込、送料別)

By

CentOS+php+MySQL+apache 「データベースのデータは正しいのにブラウザに表示すると文字化けする」を解決する

CentOS+php+MySQL+apache 「データベースのデータは正しいのにブラウザに表示すると文字化けする」を解決する
MySQLに蓄積した内容を、phpでホームページに表示する仕組みにしているのだが、データが文字化けしてしまう。
使用している文字セットは、UTF8 極力文字セットはこれで統一している。
phpで生成しているhtmlはutf8でまちがいない。
直接書いている文字は正しく表示される。
データベース内をphpMyadminなどで参照しても正しく記録されている。(DB内もUTF8で記録)
何処で文字化け?
どうもデータの出入りをコントロールしているMySQLのシステム設定あたりに問題があるようだ。
しかしこう複数のモジュールが絡んでくると原因追求が難しいよね。
紆余曲折たどり着いたのが、my.cnfのでの設定。
すぐに忘れてしまいそうなのでここにメモっておきます。
[mysqld]
に以下の2行を追加した。
default-character-set=utf8
skip-character-set-client-handshake

デフォルトのキャラクタをUTF8とし、キャラクタセットのハンドシェイクをスキップする?
ようするにそのまま引き渡すってことでしょ。
結果としてutf8の文字をそのまま渡すので正しく表示されるということですね。
但しこの方法は、場合によっては安全性に問題があるようです。
変換という工程を通過させることによって安全な文字列のみを通過させていたわけですが、
それをスキップさせてしまうわけです。
とはいえ、1から再設定というわけにもいかず、直面している問題を早急に解決しなければならないような場合には、極めて即効性のある解決方法だったりするのです。

By

Vine LINUX WordPressなどでMYSQLの外部データベースに接続するための設定

WEBサーバ+DBサーバ(MySQL)という構成で構成していたが、
最近アクセスが増え、あるタイミングで負荷がピークに、そこからほとんどフリーズ状態に陥る。
しょうがないのでサーバースペックを約3倍に増強(っていうか初期サーバが貧弱すぎ^^;)
ところが暫くするとまた同じ症状に陥る。
解決策を模索中だが、とりあえずWebサーバとDBサーバを分離することにする。
Wordpressの場合、Wp-Config.phpでMySQLへの接続設定を行っている。
データベースを外部化した場合の変更箇所は、
define(‘DB_HOST’, ‘localhost’);
この部分を外部のサーバに変更する。
ホスト名は、IPアドレスでもOKなので
define(‘DB_HOST’, ‘192.168.0.3’);
といった感で指定。
今度は、DBサーバ側のMySQL設定
同一サーバーで使用しているときは、接続ユーザのホスト名がlocalhostのみなっているはず、
これでは外部から接続はできないのでホスト名を変更するか新たな接続ユーザを追加する。
その際のホストの指定は、ローカル内のどこからでもOKとするなら
192.168.0.* (ワイルドカードも使える、もちろん特定アドレスのみもOK)

ところが一向に接続が成功しない。
色々調べるとどうやらMySQLがデフォルトで使用しているポートは、3306 らしい。
今度は、DBサーバ側の設定で、セキュリティレベルの設定で3306のポートを開放
これで接続OKとなりました。

By

PHP+MySQL データベース再構築でSQLが動かなくなった

PHP+MySQL データベース再構築でSQLが動かなくなった。
データベースの移行は、データベースのバックを行い。
新サーバで一旦データベースをCREATE、その後SQLの実行にて、バックアップしたファイル(SQL形式になっているので実行するだけでOK)を実行することにより簡単に移行できる。
ところがMySQLを利用したPHPプログラムを実行すると正常に動かないのだ。
?????
いくらチェックしても問題ない。
更に設定を見直し見るが問題なし、しょうがないのでConnectionからテストするショートプログラムを組んでテスト。
ところがConnectionは正常。でもSQLの実行結果は返ってこない。
とまぁちょっとおかしな現象だったが、結局原因はデータベース名が大文字から小文字に変わっていたのが原因だった。
しかしConnectionはTrueなのにSelectはできないって....

By

MySQL 明示的に型変換 文字列を数値に変換

MySQLは型に対する考え方がルーズで文字型のフィールドであっても中身が数字であればそのまま計算などに使用できる。
その為か、ネットで調べても型に対する記述がやたらと少ないような気がする。
みんなさらっと流しているようだ。
select max(文字型フィールド)from xxxxx

と実行すると文字列としての最大が出てしまうのだ。
※文字型フィールドには1~500の数字が入っていたとする。
気持ち的には500が出て欲しいところだが、
実際は、99が出てくるのだ。
型を意識していないとあっさりバグってしまいそうだ。
ではどうするかというと型を明示的に指定するしかない。
それには、CAST というものが用意されていた。
select max(cast(文字型フィールド as SIGNED ))from xxxxx

赤い部分で中身を整数として扱っている。
これでMAXは、500が出てくるようになる。
指定できる型には、
BINARY
CHAR
DATE
DATETIME
SIGNED (INTEGER)
TIME
UNSIGNED (INTEGER)
などがあるらしい。
http://dev.mysql.com/doc/refman/4.1/ja/cast-functions.html

現場で使えるMySQL

現場で使えるMySQL

価格:2,730円(税込、送料別)

PHP+MySQL

PHP+MySQL

価格:2,520円(税込、送料別)