rss ログイン
JJ1RLWのXOOPS Cube Siteにようこそ

メインメニュー

ログイン


ユーザー名:


パスワード:





パスワード紛失  |新規登録

オンライン状況

2 人のユーザが現在オンラインです。 (1 人のユーザが xpress ブログ を参照しています。)

登録ユーザ: 0
ゲスト: 2

もっと...

アーカイブ

カテゴリー

アクセスカウンタ

今日 : 160160160
昨日 : 385385385
総計 : 285704285704285704285704285704285704

カレンダー

2018年12月
« 11月    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

xpress ブログ » » JJ1RLW

  投稿者 ‘JJ1RLW’ のアーカイブ
WordPress for XOOPS

XOOPS 2.5.9、2.6.0(本家版)の補足

XOOPS 2.5.9、2.6.0(本家版)をインストールする際の補足で、XOOPS Cube日本語版を設置する際の相違点を説明します。
配布サイトよりダウンロードしたファイルのXoopsCore25-master.zip(2.5.9)、XoopsCore-master.zip(2.6.0)を解凍して、
htdocsディレクトリは、設置するXOOPSサイトのルート(XOOPS Cube日本語版のhtmlディレクトリに相当)となり、その下にある、
xoops_dataディレクトリは、XOOPS Cube日本語版のxoops_trust_pathと同じ様にXOOPSサイトから直接アクセス出来ないエリアに移動する。
xoops_libディレクトリは、XOOPS Cube日本語版のxoops_trust_pathに相当するのでにXOOPSサイトから直接アクセス出来ないエリアに移動する。

テストしているXOOPS 2.5.9の最新開発版のchangelog.250.txtを見ると次のバージョンは、2.5.10になる様な感じですね。

MySQL Workbench 8.0.13でのエクスポート時にエラー

MySQL Workbench 8.0.13でのエクスポート時にエラーが発生しまた。

Unknown table ‘column_statistics’ in information_schema (1109)
Operation failed with exitcode 2

環境は、クライアントがMySQL Workbench 8.0.13、サーバがMySQL 5.7.24です。(いずれもWindows)
解決策はバグレポートに記載がありました。

Bug #91640 Workbench 8 cannot export from MySQL 5.7
以下の部分の情報
———
[23 Oct 17:52] Flavio Escobar

Actually we can use an advanced option in Workbench to disable column statistics as per https://stackoverflow.com/a/52944315/1694902 – see below:

1. Go to Management/Data export
2. Choose the schema to export in the ‘Tables to export’ list
3. Click the ‘Advanced Options…’ button (top right)
4. Search for the option ‘Other/column-statistics’
5. Set the value to 0
6. Click the ‘Return’ button (top right)

According to the author of this post, “Unfortunately, you’ll have to do that every time you start MySQL Workbench.”
———
ここにある様にMySQL Workbenchのエクスポート時に、Advanced Optionsで、Other/column-statisticsの’TRUE’を’0’にすることで、エラーを吐かなくなります。

MySQL Workbenchのメインメニューを日本語化

以前からMySQL Workbenchのメインメニューを日本語化するためのxmlファイルを当サイトの「ダウンロード」より提供しています。
MySQL Workbenchのバージョンもだいぶ上がってきたので、6.3.10(x64)と8.0.13(x64)で、日本語のxmlファイルが動作するか確認して見ました。
メインメニューのコミュニティ(C)の部分はエラーとなり動作しないが、大きな問題ではないと思います。

MySQL 8.0のクラッシュ、その後3

以前にも書いたのですが、MySQL 8.0のクラッシュ、その後、MySQL 8.0.11から8.0.12にアップグレード後、mysql_upgradeコマンドを実行し、正常に終了しました。
mysqldを再起動してテストしても、やはりクラッシュしてしまいます。

今回は、システムが使うデータベース(information_schema、mysql、performance_schema、sys)以外のデータベースを一旦削除し、MySQL 5.7から改めてインポートしたら、クラッシュの発生は無くなりました。
しかし、レスポンスが異常に遅い。

どの処理が遅いのか、スロークエリーログから改善策を探すことにしました。
my.iniの内容は、
slow_query_log=1
long_query_time=2

ひとつ目の遅いクエリーは、logcounterxモジュールのlogcounterx_logテーブルを参照している
SELECT MAX(acccnt), COUNT(recid) FROM hoge_logcounterx_log;
そこで、
PRIMARY KEY (recid)

PRIMARY KEY (recid),
KEY acccnt (acccnt)

ふたつ目の遅いクエリーは、analyzer for XCモジュールのanalyzer_dataテーブルを参照している
SELECT DISTINCT d.mods, COUNT(d.mods) cnt, m.dirname FROM hoge_analyzer_data d,hoge_modules m WHERE d.analysis = 1 AND m.dirname IN ( ‘xpress’,’pico’,’d3forum’,’hypconf’,’search’,’ccenter’,’zen-cart-menu’,’sitemap’,’myalbum’,’stdCache’,’NWiki-menu’,’d3downloads’,’d3pipes’,’links’,’xoops-menu’ ) AND d.analysis = 1 AND d.date > 20000101 AND d.mods != ‘index’ AND d.mods = m.name GROUP BY d.mods, m.dirname ORDER BY cnt DESC;
そこで
PRIMARY KEY (time,ip,mods),
KEY date (date),
KEY ip (ip)

PRIMARY KEY (time,ip,mods),
KEY date (date),
KEY ip (ip),
KEY mods (mods),
KEY analysis (analysis)

以下のクエリーでインデックスを追加出来ます。
ALTER TABLE プリフィクス_logcounterx_log ADD KEY acccnt (acccnt);
ALTER TABLE プリフィクス_analyzer_data ADD KEY mods (mods);
ALTER TABLE プリフィクス_analyzer_data ADD KEY analysis (analysis);
※2018/10/15追記

いずれもインデックスを追加することで、劇的にレスポンスが改善されましたが、まだMySQL 5.7の2~3倍の処理時間が掛かっています。

しかし、以前のクラッシュの原因については不明です。
推測ですが、データベースを作成した際に不具合が紛れ込んだのかも知れません。

試しに再び、MySQL 8.0での運用をしばらく続けようと思います。

周辺市町村のハザードマップをチェックして見た

西日本豪雨、台風21号や北海道地震で被災された皆様に心よりお見舞い申し上げます。

最近、自然災害が多い様に感じ、改めて周辺市町村のハザードマップをチェックして見ました。

チェックしたのは、香取市、多古町、匝瑳市、旭市などの千葉県北東部です。
中でも、判り易くまとめられていたのは、匝瑳市のハザードマップです。

土砂災害、大雨や津波での浸水域を地図上に表示されているので、一目で判る様に上手くまとめられ、より詳細な情報は別に示されいます

参考サイト
香取市 – 災害への備え
多古町 – 災害に備えて
匝瑳市ハザードマップ
旭市 – 「旭市防災マップ」を配布します

Raspberry Pi3(ルーター)初めてのトラブル

Raspberry pi3(ルーター)初めてのトラブルを経験しました。

昨日(2018/08/13)16時過ぎ頃に停電(瞬間停電)があった様で、マイロSDカードのルートファイルシステムに矛盾が発生し、起動時にエマージェンシー(メンテナンス)モードになって入力待ち状態で止まって、普通に起動してくれない。

Give root password for maintenance
(or type Control-D to continue):
の様なメッセージで入力待ち状態で止まる。

ディスプレイ、マウス、キーボードを繋ぎ、入力待ち状態でrootのパスワードを入力してログインし、

umount /dev/mmcblk0p2
fsck -y /dev/mmcblk0p2
reboot

正常に起動していることを確認してトラブルシューティングは終わりです。

参考サイト
RaspbianでWelcome to emergency mode!
Linuxを強制終了した場合に、起動不良→回復方法

PHP7対応のまとめ

以前に投稿したxpress ブログのPHP7対応の記事を資料室にまとめて見ました。

※リンクをクリックするとブラウザの新しいウインドウが開きます。
xpress ブログ記事へのリンク、
Analyzer for xcの改造
Analyzer for XC Ver 0.51のPHP7対応
Analyzer for XC Ver 0.51のPHP7対応その2

logcounterx Ver 2.74のUTF-8、MySQL、PHP7対応

myx_backup Ver 1.10のPHP7対応

PHP7とXOOPS Cube環境下でのPHPエラーメッセージ

zen-cart Ver1.5.1-jpのPHP7対応での変更点

資料室の記事へのリンク
Analyzer for XC Ver 0.51のPHP7対応などまとめ

logcounterx Ver 2.74のUTF-8、MySQL、PHP7対応などまとめ

myx_backup Ver 1.10のPHP7対応まとめ

PHP7とXOOPS Cube環境下でのPHPエラーメッセージ

zen-cart Ver1.5.1-jpのPHP7対応での変更点

MySQL 8.0のクラッシュ、その後2

MySQL 8.0のクラッシュ、その後、MySQL 8.0.11から8.0.12にアップグレード後、mysql_upgradeコマンドを実行し、正常に終了しました。
mysqldを再起動してテストしても、やはりクラッシュします。

MyISAMとInnoDBの両方のデータベースエンジンで、クラッシュが発生します。
作成したばかりのデータベースで、「SHOW TABLE STATUS FROM hogehoge」のクエリーでクラッシュが発生します。
やはり、以前と同じで、
[ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: row0sel.cc:4603
とのエラーログが出力されて、mysqldが落ちてしまいます。

ほかにもクエリーの応答時間が、MySQL 5.7と較べて「激遅」なのも問題です。

MySQL 8.0のバージョンアップで改善することを期待していましたが、改善していません。

DDNSの情報が他のDNSに反映されない

2018/07/13~16にかけて、DDNSの情報が他のDNSに反映されない状況となり、当サイトにアクセス出来ませんでした。

当サイトが利用しているDDNS(ieServer.netのDDNSサービス)は、結構堅牢なサーバ構成をとっているので、トラブルはめったに無いのですが、一応、DDNSの管理者に連絡し対応して頂きました。

DDNSを無料で提供してくれている管理者の方に感謝します。

参考サイト
無料ダイナミックDNS(DDNS)サービス

MySQL 8.0のクラッシュ、その後

MySQL 8.0のクラッシュ、その後、MySQL 8.0インストール初期のmy.ini(my.cnf)を使って、mysqldを起動してテストしても、やはりクラッシュします。

MyISAMとInnoDBの両方のデータベースエンジンで、クラッシュが発生します。
作成したばかりのデータベースで、「SHOW TABLE STATUS FROM hogehoge」のコマンドでクラッシュが発生します。
MyISAMのデータベースを選択した場合でも、
[ERROR] [MY-012856] [InnoDB] InnoDB: MySQL is trying to perform a consistent read but the read view is not assigned!
[ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: row0sel.cc:4603
とのログが出力されて、mysqldが落ちてしまいます。

MySQLのバグリポートに「Bug #90694 Server crashes」という同様の現象が報告されているが、解決策は不明です。

MySQL 8.0ではシステム関連テーブルがInnoDBになっているので、MySQLのシステムに近いレベルで、エラーが発生している様に思えます。
MySQL 8.0の次のバージョンで改善することを期待したいと思います。

※2018/07/04バグリポートについて追記


 

Powered by XOOPS Cube 2.2 © 2001-2016 XOOPS Cube Project Distributed by XOOPS Cube 2.2 Distribution Team.