Server/移行/履歴

1GBチャレンジ†

CDNになってキャッシュが多くなってきたので行けるのではと。 Spring同居してなければ500M程度のあまりがあるが、起動すると100M程度になるので、swap必須(KAGOYAはデフォルトでswapない)

PHPダウングレード†

yum remove php-json php-pgsql php-mbstring php-pdo php-xml php-cli php-mysqlnd php-common php-gd php
yum install --enablerepo=remi,remi-php72 php php-mbstring php-pgsql php-gd php-xml php-mysql

再起動に時間がかかる問題†

2019/06ごろからお名前.com VPSのみimport直後に発生するようになった。ただし８月下旬には解消した。

190729 15:00:06  InnoDB: Starting shutdown...
190729 15:01:07  InnoDB: Waiting for master thread to be suspended
190729 15:02:07  InnoDB: Waiting for master thread to be suspended
190729 15:03:07  InnoDB: Waiting for master thread to be suspended
190729 15:04:07  InnoDB: Waiting for master thread to be suspended
190729 15:05:07 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

SQS移行後の手順†

1. tools.rutake.comのdns変更
2. consumerなるべく消化させる
3. consumer止める
4. バックアップ
5. toolsのDNS切り替わりをもって、consumer手動再開
6. mvn gradleが時間かかるのでテンポラリーならスキップ！

DNS切り替え時間†

15分単位でバッチが動くようで最短16分で反映確認できた。

healess chrome残タスク†

1. chrome driver
2. root以外でjavatool

CME†

select * from market_records where id >697982;

障害履歴†

2020年のトラブル†

スナップショットが終わらない問題†

3/11 19:53からスナップショットロールバックが終わらない。21:50頃問い合わせ 3/12 キャプチャーをつけて対応依頼 電話10回以上時間帯を変えてかけるもつながらず 結局データ不整合で3/18 22:00に復帰

漏れ串†

S3検証でまさかのオープンproxyとなること5か。あまりにCONNECTが多いから調べてみたらという状況でログをみること！

CloudFlare API不発†

2020/01/21に遭遇。エラーではないのにdnsが切り替わらない。2日後に試したら自然復旧してたので向こうのバグだろう。

pip install psycopg2†

2020/01/21に遭遇。同じバージョンで12月構築したときは大丈夫だったのだが・・・。conoha1/26再構築バージョンでは解消！だがonamae VPSでは解消せず。2020/10ごろに試してみたら解消していた。

• setuptools古い 変わらず
• pip古い　変わらず

mysql restoreされず†

もともと使ってないDBをリストアするという潜在バグを抱えていたのだが、ansible側がDB指定で取り込みしてなかったため助かっていた。 しかし2020/09以降はきちんと指定のDBのみ取り込むようになったため顕在化。

それ以前のトラブル†

DNS切り替わらない問題†

• Windows 10バッチマシンからDNSがいつまでたっても昔のIPを参照している問題
• 最初はドメイン記載ミスでワイルドカード扱いになりGMOにいっていた
• それを解消したけどダメ、次はDNS設定。しかしコマンドラインからは正しく新IPが出る。

https://www.glamenv-septzen.net/view/1346

OOMKiller対策†

Oom Killerになりそうなプロセスを見る†

dstat --top-oom

Oom Killer発動したら再起動させる†

vm.overcommit_memory=1 #over commitの無制限許可。2だと不許可
vm.panic_on_oom=1
kernel.panic=30

https://blog.supersonico.info/?p=321

上記設定とhtop(多分無実)を入れたあとに不安定になった可能性があるので導入は控える。over commitの無制限許可が真犯人。

年度毎の記録†

2019†

2018†

ついにさくらのVPS卒業！PHP7化を11月に実施

2017†

2016†

自宅サーバーを一時的に使う計画†

• セットアップは最低限とする
• MySQLはslave稼働しておき、切り替えるだけにする。
• 昔あった切り替えタスクとread_onlyを外す（入っているはず）を手元で練習だな。あといい加減IPで持ったほうが良い

MySQL再起動問題†

再起動に5分。recoveryの後Index再作成でも走るのかと思ったが、シャットダウン時に落ちないプロセスがいて終了を待っていた模様。バグと出ていたので再発するようであればリブートはなくす方向で！3/28のみ発生。3/30は発生せず

MariaDB落ちる問題†

180425  7:48:01  InnoDB: Starting shutdown...
InnoDB: Warning: 1 threads created by InnoDB had not exited at shutdown!
180425  7:49:42  InnoDB: error: return value 16 when calling
InnoDB: pthread_mutex_destroy().
InnoDB: Byte contents of the pthread mutex at 0x55c575571830:
 len 40; hex 00000000000000000000000001000000030000000000000000000000000000000000000000000000; asc                                         ;
180425  7:49:42  InnoDB: Assertion failure in thread 139859370972928 in file os0sync.c line 258
InnoDB: Failing assertion: pthread_cond_destroy(cond) == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
180425  7:49:42 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Ansible化全体計画†

2012/04†

さくらのVPS512から1Gへ移行。

スケジュール†

• 2012/04/04

apacheコンテンツ移行。DBインポート完了。設定まだ。wiki.rutake.com移行完了

• 2012/04/05

DB設定完了。cakephp,blog.rutake.com移行完了

• 2012/04/09

SVN移行完了。SSLはIP指定をしているのでそこを変えないといけなかった。

• 2012/04/11

Cronジョブ移行。バックアップでDBパスワードが変わっていたためそれなりにシェルを変更

トラブル†

• PostgreSQLのEUC_JPのＤＢを作成するときにそのままだとエラーが出るようになった。-T template1で回避

• PostgreSQLの仕様変更により、date型をsubstrする場合は明示的にtext型にする必要が生じた。substr(userdate::text,4,3)

• MySQLの全部のデータを移行したが、ユーザ認証のみできない。コマンドラインから権限変更もできない状態だったので、phpMyAdminから該当ユーザ削除→追加で復旧。後日flush privilegesでＯＫということが判明

2013/07 自宅内サーバー移行†

一か月かけて準備。普段からrsyncでデータの同期はとっていた。

トラブル†

IP変えて再起動したら反応せず。コンソールから復旧させたが、原因不明だった。 ファイヤーウォールでSquidのポートを通していなかった。こちら設定漏れが多いので注意。Sambaのユーザー移行漏れ！

2013/12 さくらVPS再構築†

下準備†

まずは、それほどアクセスのないページや自分専用コンテンツなどを自作サーバーに移行する。基本的にhttpd.confとssl.confを持ってきて、SVNのアクセス制限元を変更するぐらいで動いた。ssl.conf持ってこないとSSLに強制接続になるので今後の課題。

移行対象†

1. tools.rutake.com以下のアプリ
2. wiki.rutake.com

要塞化†

• SSHDのアクセス元制限。ポートを閉じる。

tools.rutake.comのpostgres移行†

1. postgres自動起動の設定
2. DBインポート(DB作成必要)
3. PHPツール移植(ツールは問題なしだが、DB接続で下記問題発覚)

• トラブル発生

psql: FATAL:  Ident authentication failed for user "postgres"
SQLSTATE[08006] [7] FATAL: Ident authentication failed for user "postgres"

• pg_hda.confを下記のように編集し再起動。ローカルからのUNIX接続をOKにした。

# "local" is for Unix domain socket connections only
local   all         all                                trust

• PHPからの接続は元の設定をコメントアウトし、パスワード認証をかけるようにした。

#host    all         all         127.0.0.1/32          ident sameuser
host     all         all         127.0.0.1/32          md5

• 12/4 toolsのpostgres部分移行完了(一部svn登録モレモジュールがあり消滅･･･)

• CakePHPをTools配下へ移植

2.4にしてみた。いつものようにhttpd.confの設定が必要。 appのみSVNからコピーして無事接続成功

DB単位でエクスポート
mysqldump -u root -p MYDATABASE > /var/tmp/MYDATABASEdmp.sql
移行元のDBを消す。
[root@epox cake2.4]# mysqladmin -u root -p drop MYDATABASE
空のDBを作成
mysql> create database MYDATABASE default charset utf8;
インポート
mysql -u root -p MYDATABASE < MYDATABASEdmp.sql

• 12/5 cakephpのツールを移行完了。残る大物はblogのみ

• 12/7 バックアップを実施だが、mysqlがパスワードなしでバックアップできている理由が不明。コマンドラインにもろ記載が後日判明

• 12/30 blogの移行テスト。DB移動とblog以下一括移動が一番楽とのことでそれで実施。コンテンツ領域20MとDBが2M

目的のディレクトリの一階層上に移動
cd /var/www/UPPER_DIR
tar cvzf blog.tar.gz blog/

DBも同じようにバックアップして圧縮しておく(18Mが十分の一に）

受け取りサーバー側では同じく一階層上で解凍
DBもインポートしておく
空のDBを作成(utf-8でOK)
mysql> create database MYDATABASE default charset utf8;
インポート
mysql -u root -p MYDATABASE < MYDATABASEdmp.sql

• 12/31 空室情報取得バッチの移植に苦労。理由は<?phpを入れてなくてバッチ実行クラスが見つからないというなんとも初歩的なもの。翌日に移植完了とhtml形式の違いで取得できなかったものにも対応。

• 1/1 テーブル移行

移行元
mysqldump -u root -p --add-drop-table cakephp rooms > rooms.sql
gzip rooms.sql
移行先
gzip -d rooms.sql.gz
mysql -u root -p cakephp < /var/tmp/rooms.sql

• 1/1 httpdのカウントテーブル作成

  mysql> CREATE TABLE httpd_count (
      ->  recorded DATETIME not null,
      ->  httpd_count int unsigned not null
      -> );
  mysql> LOAD DATA LOCAL INFILE '/var/log/httpd_count.log' INTO TABLE httpd_count   FIELDS TERMINATED BY ',';

• 1/6 svn移行

svnadmin dump /home/svn/repos | gzip > /var/tmp/myrepos.tar.gz

• 1/6 夜移行

サーバー再インストールからコンソール上がりきるまで10分は見ておいたほうがよい。DNSがなかなか切替わらず見切り発車で実施。SSLの秘密鍵のバックアップを忘れてSSL月だと起動失敗したのでSSLは後日。blogとwikiは移行完了。cronの改行コードがおかしくてエラーとなっていた。LFじゃないとＮＧ

• 1/16 セキュリティ設定

SVN移行,hosts設定,

• 1/17 IP設定 210.148.59.13,serverToken除去,php.iniの設定変更など

移行漏れ†

SSL証明書,.htpasswd

移行前の下準備†

1. 公開鍵のバックアップ(OK)
2. blog関係バックアップ
3. cron関係チェック(OK)
4. yumの履歴(OK)
5. SVNバックアップ(OK)

• 2/4 UTF-8移行

createdb homedb_uft -E UTF-8 -T template0 
ダンプSQLをUTF-8に変換
SET client_encoding = 'UTF-8';

• 4/19 cakephp戻し

データベース移行は順調。
シンボリックリンクを介してのリライトはＮＧのようなのでディレクトリ名変更
DBアクセス。ユーザーを追加していなくてアクセス失敗。
simple_dom_htmlライブラリを入れてなくて失敗

• 6/02 pukiwiki更新検討

2015/04 攻撃を受けてセキュリティ強化とアプリケーション分離と作り直し†

基本方針†

内部向けは自宅サーバーにおいておくか？ wikiはアクセス数が減少しているのでどうする？ 旧MTのコンテンツを廃止したい。

対象†

作業手順†

トラブル†

2015/11 一部アプリケーション分離†

移行スケジュール†

Ansible状況†

チェックリスト†

1. 認証周りがキチンとされているか?(管理画面に入ること)
2. 旧コンテンツ(blog/techmemo)やwikiのリダイレクトが完璧であること。
3. アクセス制限が移行されていること

postgresのユーザーに権限付与(シーケンスリード権限がなかった)†

GRANT ALL ON テーブル名 TO ユーザー名;
GRANT ALL ON シーケンス名 TO ユーザー名;

cron移行周りのはまり（現在進行中)†

• ntpdateが見えない フルパスに変更

• さくらでaws configureの内容が見えてない。翌日cron経由だと動かなくて発覚。 →単なる設定ミス。

aws s3 lsで設定の確認をすること

• 未解決

/etc/cron.daily/s3_backup.shがさくらだけ上記のエラーがでる。 5分ごとに実行だとでないのに！

wordpressのサブディレクトリからサブドメインへ移行†

1. http://blog.shun-ichiro.com/howto/move-wordpress/

*メニュー編集

コンピュータ関係

• DataBase
• Linux
• PC-UNIX
• Programming
• PC情報

その他趣味系(別wiki)

• 自動車
• 温泉
• スキー情報

外部リンク

• 旧　技術メモブログ
• 新　技術メモブログ
• ランチブログ
• NIFTYにあるHP
• 旅行記写真館

今日の訪問 1

オンライン人数 2

最新の20件

人気の20件

今日の20件