Monthly Archives: 3月 2013 - Page 2

ニキシー管時計 ケース作成

だいぶ今更感がありますが、ニキシー管時計のケースを作成しました。
私には美的センスというものは無いためどういうデザインが良いか悩みましたが、結局加工しやすく比較的機能的であるべきということて画像のようになりました。

image

木材は紫檀を使用し、接着で固定しました。

image

ティッシュ箱みたいな仕組みで上から被せて固定します。

image

レトロ感を演出させるため木目オイルを塗り研磨してみました。

image

image

これで寝室にもリビングにも置けるようになったのかな?
ニキシー管特有の温かみのある光は幻想的で見ていて飽きないですね〜。

MySQL データベース 起動しない 全データベースのダンプ CentOS5.7

データベースへの書き込みが頻繁に行われないサーバである場合は良いがデータベースへの書き込みが頻繁に起こるサーバでは突然電源が切れた場合などに不整合を起こしてMySQLが起動しなくなる事がある。
今回その対応策を記録しておきたいと思う。

起動不能となった時に”/var/log/mysqld.log”へ吐かれるログ

13:22:06 UTC - 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.
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.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338528 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x7b4e5e]
/usr/libexec/mysqld(handle_fatal_signal+0x3e2)[0x6813c2]
/lib64/libpthread.so.0[0x311a80ebe0]
/lib64/libc.so.6(gsignal+0x35)[0x311a030285]
/lib64/libc.so.6(abort+0x110)[0x311a031d30]
/usr/libexec/mysqld[0x85b911]
/usr/libexec/mysqld[0x85ce80]
/usr/libexec/mysqld[0x920b32]
/usr/libexec/mysqld[0x917b6c]
/usr/libexec/mysqld[0x85a7e5]
/usr/libexec/mysqld[0x84e263]
/usr/libexec/mysqld[0x85141b]
/lib64/libpthread.so.0[0x311a80677d]
/lib64/libc.so.6(clone+0x6d)[0x311a0d325d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

強制リカバリーモードの設定を行う
# vi /etc/my.cnf

[mysqld]
innodb_force_recovery = 3 # 項目の最後に追記

MySQLを再起動する
# service mysqld restart

データベースのダンプ

# 全データベースのダンプを行う
# mysqldump --events -u root -p -x --all-database > all-database.sql
# ユーザ情報のダンプ
# mysqldump --events -u root -p -x --allow-keywords mysql > allow-keywords.sql

MySQLを停止する
# service mysqld stop

データベースを格納しているディレクトリを移動(バックアップ)する
場所が不明な場合は設定ファイル内の”datadir”を参照する
# mv /var/lib/mysql /var/lib/mysql_bkup

再度データベースを格納するディレクトリを作成する
# mkdir /var/lib/mysql

所有者をmysqlユーザとする
# chown mysql:mysql /var/lib/mysql

強制リカバリーモードの設定を解除する
# vi /etc/my.cnf

[mysqld]
#innodb_force_recovery = 3 # エスケープする

MySQLを起動する
# service mysqld start

ダンプしたデータベースをインポートする

# mysql -u root < all-database.sql
# mysql -u root mysql < allow-keywords.sql

再発しない事を確認するため念のためにMySQLを再起動する
# service mysqld restart

参考サイト
またデータベースサーバがダウンしてました
似非管理者の寂しい夜:MySQLのバックアップではユーザー情報は含まれない – livedoor Blog(ブログ)