最新版で試したが、ディフォルトでは、投稿などが保存されなかった。設定のパーマリンクのところは、[基本]にするとうまく動作するようになった。何らかの環境の違いが影響している？と思われる。
2024年4月6日土曜日
2022年9月15日木曜日
Sqlite dump backup restore ＆ 初期化
SQLiteのバックアップと復元は、こんな感じでできる。
backup
sqlite3 db.sqlite3
sqlite> .databases
sqlite> .output /dirname/test.dump
sqlite> .dump table_name
restore
% rm db.sqlite3
% sqlite3 test.dump < test.dump
sqlite3 db.sqlite3
sqlite> .databases
sqlite> .output /dirname/test.dump
sqlite> .dump table_name
restore
% rm db.sqlite3
% sqlite3 test.dump < test.dump
****************
初期化したいときは、各アプリのmigrationsフォルダとdb.sqlite3をするといいという説明のサイトがあったので、実際やってみたが、うまくいかない。
別のサイトの情報では、migrationsフォルダの中の_init_pyは残して、他は削除とあった。この方法だとうまくいった。と、思ったら、エラーメッセージが出て、0001_initial.pyが必要という指示が出る場面があった、指示通りバックアップからファイルを追加したら、解決したというものもあった。微妙に調整が必要な場合もある？ようだ。そういうことに備えて、migrationsも、バックアップとってから削除したほうがいいかもしれない。
2016年1月23日土曜日
SQLのLEFT JOINの活用
グループウエアで、未読管理をしていたが、既読の場合にログにとして記録していく方式をとっていたため、時間がたつにつれ、どうしても反応が遅くなることに気がついた。
EXISTSでサブクエリなど使うことなど検討したが、どうやらもっといい方法があることを、たまたまネット上で見つける。
http://kkoudev.github.io/blog/2013/09/14/sql/
上記のサイトを参考にさせていただきました。わかりやすく説明されています。
実際LEFT JOINで、いろいろ検索条件をしぼってやってみたところ、レスポンスが劇的に改善しました。
EXISTSでサブクエリなど使うことなど検討したが、どうやらもっといい方法があることを、たまたまネット上で見つける。
http://kkoudev.github.io/blog/2013/09/14/sql/
上記のサイトを参考にさせていただきました。わかりやすく説明されています。
実際LEFT JOINで、いろいろ検索条件をしぼってやってみたところ、レスポンスが劇的に改善しました。
2015年8月2日日曜日
グループウエアのアクセス集中緩和策
アクセス集中時の対策として、WEBサーバーとDBサーバー、どちらも分散化する方向で考えてみた。ゆくゆくはロードバランサーということなんだろうが、はたして、中古のPCでそれは可能か微妙である。
とりあえず、グループウエアのデータベースの書き込みと添付ファイルのアップーロードはマスターのサーバに送り、分散したサーバには、読み取り専用のスレーブDB、添付ファイルを置くことにした。Mysqlのレプリケーション、ファイルに対するrsyncで対処しようと考えている。うまくいけばいいのだが。
そういえば、アマゾンなども、情報をアップしても反映されるまで、時間がかかる。世界規模で、閲覧されるわけだから、多少の時間差もないとレプリケーションのようなこともむずかしいだろう。今回の件で、そのへんの事情がよくわかる気がする。
とりあえず、グループウエアのデータベースの書き込みと添付ファイルのアップーロードはマスターのサーバに送り、分散したサーバには、読み取り専用のスレーブDB、添付ファイルを置くことにした。Mysqlのレプリケーション、ファイルに対するrsyncで対処しようと考えている。うまくいけばいいのだが。
そういえば、アマゾンなども、情報をアップしても反映されるまで、時間がかかる。世界規模で、閲覧されるわけだから、多少の時間差もないとレプリケーションのようなこともむずかしいだろう。今回の件で、そのへんの事情がよくわかる気がする。
2015年8月1日土曜日
Mysql レプリケーション
Mysqlのレプリケーションの設定をやってみた。
以下のリンクを参考にさせてもらった。
http://dotnsf.blog.jp/archives/1028720878.html
１ マスターで
mysql > GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.0/255.255.255.0' IDENTIFIED BY 'password';
ネットワークアドレスの指定のため、192.168.1.0の最後は0とすることに注意
/etc/mysql/my.cnf
[mysqld]
log-bin=mysql-bin →もとのファイルではlog_binとなっていたが、log-binでいいようだ。
server-id=1001
として、service mysql restart
２ スレーブで
mysql > GRANT ALL PRIVILEGES ON *.* TO 'repl'@localhost IDENTIFIED BY 'password';
my.cnfの編集
[mysqld]
log-bin=mysql-bin
server-id=1002 として service mysql restart
３ マスターで
mysql > FLUSH TABLES WITH READ LOCK;
mysql > SHOW MASTER STATUS;
このとき、Fileのmysql-bin.00000?（６桁数字） Positionの３桁数字 をメモしておく
別のコンソールで
# mysqldump -u root -p mydb --lock-all-tables > mydbdump.db によりデータを保存
もとのコンソールで
mysql > UNLOCK TABLES;
４ データの移動
mydbdump.dbをスレーブに移動
５ スレーブで
# mysql -u repl -p mydb < mydbdump.db
mysql > CHANGE MASTER TO
MASTER_HOST='192.168.1.XXX',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000031', ←３でメモした値
MASTER_LOG_POS=285; ←〃
mysql > START SLAVE;
※以上だが、実際にはうまくいかなかった。原因はいくつかあった。
・http://pyoonn.hatenablog.com/entry/2015/01/09/133102が参考になりました。どうやらコネクトしてないようだった。
# mysql -h 192.168.*.* -u repl で、接続確認しても、エラー
マスターで
grant all privileges on *.* to repl@"192.168.58.%" identified by 'password' with grant option;
で特権を与える。192.168.58.*のワイルドカードのホストのreplからアクセス可能に
スレーブで確認するには
mysql>SHOW SLAVE STATUS\G
このとき、Slave_IO_Running: Yesが表示されればOKだが、まだ、だめ
・さらに、iptablesがじゃましてないか確認したが、ディフォルトでOFFなってたので、関係なかった。
・そこで、
http://d.hatena.ne.jp/uriyuri/20081024/1224798772を参考にさせていただいた。
/etc/mysql/my.cnfの設定では
bind-address = 127.0.0.1
bind-address = (接続したいマシンのIPアドレス)
と、接続先を追加していくか、または、どのIPからも接続許可したいなら、いっそbind-addressをコメントアウトすればよいということらしい。
これで、なんとか、動くようになった。
※ひとつレプリケーションで注意が必要なことがあるようだ。
http://nippondanji.blogspot.jp/2009/03/mysql10.html にあるように
スレーブのデータは変更しないということ。
グループウエア等の設定では、十分注意が必要なところなようだ。
以下のリンクを参考にさせてもらった。
http://dotnsf.blog.jp/archives/1028720878.html
１ マスターで
mysql > GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.0/255.255.255.0' IDENTIFIED BY 'password';
ネットワークアドレスの指定のため、192.168.1.0の最後は0とすることに注意
/etc/mysql/my.cnf
[mysqld]
log-bin=mysql-bin →もとのファイルではlog_binとなっていたが、log-binでいいようだ。
server-id=1001
として、service mysql restart
２ スレーブで
mysql > GRANT ALL PRIVILEGES ON *.* TO 'repl'@localhost IDENTIFIED BY 'password';
my.cnfの編集
[mysqld]
log-bin=mysql-bin
server-id=1002 として service mysql restart
３ マスターで
mysql > FLUSH TABLES WITH READ LOCK;
mysql > SHOW MASTER STATUS;
このとき、Fileのmysql-bin.00000?（６桁数字） Positionの３桁数字 をメモしておく
別のコンソールで
# mysqldump -u root -p mydb --lock-all-tables > mydbdump.db によりデータを保存
もとのコンソールで
mysql > UNLOCK TABLES;
４ データの移動
mydbdump.dbをスレーブに移動
５ スレーブで
# mysql -u repl -p mydb < mydbdump.db
mysql > CHANGE MASTER TO
MASTER_HOST='192.168.1.XXX',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000031', ←３でメモした値
MASTER_LOG_POS=285; ←〃
mysql > START SLAVE;
※以上だが、実際にはうまくいかなかった。原因はいくつかあった。
・http://pyoonn.hatenablog.com/entry/2015/01/09/133102が参考になりました。どうやらコネクトしてないようだった。
# mysql -h 192.168.*.* -u repl で、接続確認しても、エラー
マスターで
grant all privileges on *.* to repl@"192.168.58.%" identified by 'password' with grant option;
で特権を与える。192.168.58.*のワイルドカードのホストのreplからアクセス可能に
スレーブで確認するには
mysql>SHOW SLAVE STATUS\G
このとき、Slave_IO_Running: Yesが表示されればOKだが、まだ、だめ
・さらに、iptablesがじゃましてないか確認したが、ディフォルトでOFFなってたので、関係なかった。
・そこで、
http://d.hatena.ne.jp/uriyuri/20081024/1224798772を参考にさせていただいた。
/etc/mysql/my.cnfの設定では
bind-address = 127.0.0.1
bind-address = (接続したいマシンのIPアドレス)
と、接続先を追加していくか、または、どのIPからも接続許可したいなら、いっそbind-addressをコメントアウトすればよいということらしい。
これで、なんとか、動くようになった。
※ひとつレプリケーションで注意が必要なことがあるようだ。
http://nippondanji.blogspot.jp/2009/03/mysql10.html にあるように
スレーブのデータは変更しないということ。
グループウエア等の設定では、十分注意が必要なところなようだ。
登録:
投稿 (Atom)