mariadbのデータフォルダ移動、シンボリックリンクが一番!

以前、スティックコンピュータで、mariadbのデータフォルダをmicroSDに移したという話を書いたが、その時は、my.cnfの設定を変更したものだった。今回、VPSのmariadbはそれでも簡単にいかなかったので、新しいフォルダ/data/mysqlに、/var/lib/mysqlからのシンボリックリンクを貼ってやってみた。難なく、それだけで、全て片付いた。これが一番楽チンだ。以下の方法は、CentOS用です。他は、コマンドが違うかも。

(1)mysql (mariadb) を止める ← 重要
(3)新しいフォルダを作成しオーナーを変更する
sudo chown mysql:mysql /data/mysql
(3)新しいフォルダーに全部コピーする
sudo cp -pr /var/lib/mysql/* /data/mysql/
(4)元のフォルダーをrenameして使えなくしておく(万が一のために元に戻せるように)
(5)シンボリックリンクを貼る
sudo ln -s /data/mysql/ /var/lib/mysql
とこうなる。
lrwxrwxrwx  1 root    root      12 11月 23 15:35 2018 mysql -> /data/mysql/
(6)mysql (mariadb)  を再スタートする

"Index column size too large. The maximum column size is 767 bytes." への対応

外に借りているVPSサーバーにmariadbが入れてある(何を隠そう、このサイトは、このVPSに載せてある。格安でありながら、結構使い勝手がいいので気に入っている)。ただ、バージョンは古く、MariaDB-server-5.5.60である。10.3とかにすればいいのかもしれないが、問題は、先に作ったtwitterの頻度データをそこに載せる必要があったのだが、パソコンで作ったデータベースをdumpして、移行しようとしたら、リストアするときに、

Index column size too large. The maximum column size is 767 bytes

というエラーで止まってしまうのだ。インデクスのサイズが小さすぎるらしいが、ネットにあるいろいろな対応を試みたが、うまくいかなかった。

最終的にどうしたかだけ、いや、多分この操作が良かったのだろうというところだけ書いておく。

ちなみにVPSは、CentOs の6.9あたりが入っている。これもあまり新しくない。今更、バージョンアップするのも面倒だ。

さしあたって、https://blog.cles.jp/item/9965に書いていただいているような対応をする(参考にさせていただいて感謝します)。要は、/etc/my.cnf.d/server.cnfに、

[mysqld]
innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix = on
innodb_default_row_format = DYNAMIC # この設定が効かない場合には以下を参照

を書き加えるのだ。が、私の場合、最後の文章を入れてmariadbを再起動すると、失敗した。したがって、これは、入れることができない。ありがたいことに、それがダメな場合はというコメントで、以下のようにするといいと書いてある。

CREATE TABLE `hogetable` (
id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;

ところが、私の場合、テーブルを作るのではなく、ダンプしたものをリストアするのであるから、このような、テーブルを作るプロセスそのものはない。ダンプの仕方を色々変えてもやってみた。indexを抜いた形でdumpして、リストアして、その後、indexを作成したりもしたが、結局同じエラーが出る。

indexを抜けば、普通にリストアできるが、index抜きで使ったら数百万のデータを検索する時間は、ほぼ使い物にならないくらいかかってしまう。

結局、150メガもあるだぷファイルの中身を見ることにした。すると、それはテキストファイルで、全てのデータベース操作がそこに書いてあるものなのだ。そして冒頭に、次のような、テーブルを作成するコマンドが書かれていた。

CREATE TABLE `tweetedwords` (  `word` varchar(200) NOT NULL,  `part` varchar(5) NOT NULL,  `frequency` int(15) NOT NULL,  KEY `twitterword` (`word`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

なんだ、そうか!という感じだ。ここに、先に教えてもらった ROW_FORMAT=DYNAMICを書き込んだら、見事、リストアできた。つまり

CREATE TABLE `tweetedwords` (  `word` varchar(200) NOT NULL,  `part` varchar(5) NOT NULL,  `frequency` int(15) NOT NULL,  KEY `twitterword` (`word`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;

と変更しただけである。

良かった、良かった。

MacのphpMyAdminが動かなくなって

以前まで正常に動いていたphpMyAdminが突然動かなくなった。phpファイルを生で表示してしまう。apacheのphpモジュールの問題なのか色々探ったが、解決しない。多分、OSが更改されたための問題のようだが、わからない。

apache2から起動するのを諦めて、phpのバージョン7が入っているので、その内蔵のウェッブサーバーから起動することにした。

やり方は簡単だ。phpMyAdminのシステムは、/Library/WebServer/Documents 以下においてあるので(http://www.ibot.co.jp/wpibot/?p=131 参照)そこで、

php -S localhost:8000

と打てば、phpの内臓サーバーが起動する。ブラウザでアドレス

http://localhost:8000/phpmyadmin/

を指定すれば良い。これ以外に、macのウェブサーバーを利用するつもりがないときは、これで十分だ。

上記については、以下のサイトを参考にさせていただいた。
https://qiita.com/masahirok_jp/items/c4f0d8bb5f55a114e31b

phpMyAdminをMacで動かす

以前も、mysql (実質的に同じ mariadb)を動かすとき、phpMyAdminを使っていた。便利だった。今回また、色々データーベースをいじるのに、使おうと思ったが、macを新しくしているせいか動かなかった。
apacheは、標準のものでいいはずだ。ただ、設定ファイルなどがどこにあるかを確認しておかなければならない。

/etc/apache2/httpd.conf

である。
php も、動いていた。標準なのか、何気にインストールしたのかは記憶が定かではない。

homebrewで、phpmyadminをインストール。

brew install phpmyadmin

と最後に、https.confに付け加える設定が出ているので、そのまま貼り付ける。また、https.confの中のモジュールの追加起動が必要だった。

LoadModule php5_module libexec/apache2/libphp7.so
LoadModule userdir_module libexec/apache2/mod_userdir.so
Include /private/etc/apache2/extra/httpd-userdir.conf

だったと思う。これでapacheを再起動する。(もう一つ何か必要だった気がするが・・・・・・)
さらに、正常起動できると

The $cfg['TempDir'] (./tmp/) is not accessible. phpMyAdmin is not able to cache templates and will be slow because of this.

というような、警告が出ていて、遅くなるっていうものだから、対応せざるを得ない。

これは、/usr/local/share/phpmyadminの下に、tmpファイルを作成し、所有者をwwwに変更すると消える。