debianのパッケージ postgresql-9.1 (9.1.11-0wheezy1) を通常インストールした状態で、 EUC-JPエンコードのデータベースを作成しようとしたら、 $ createdb -E EUC_JP -T template0 MyDB createdb: データベースの生成に失敗しました：ERROR: 符号化方式 EUC_JP がロケール ja_JP.UTF-8 に合いません DETAIL: 選択された LC_CTYPE を設定するには、符号化方式 UTF8 である必要があります。 という結果に。 $ createdb -E EUC_JP -l C -T template0 MyDB とすれば、とりあえずデータベースを作成できるが、 ソート順が辞書順にならないなど、日本語関係の処理に違和感があるかもしれない。 その場合は、EUC-JP用の日本語ロケール(ja_JP.eucjp)を用意すればよいらしい。 具体的には、 $ locale -a で、ja_JP.eucjpロケールがないのを確認し、 $ sudo vi /etc/locale.gen で、ja_JP.EUC-JP EUC-JP の行をアンコメントし、 $ sudo locale-gen で、ja_JP.eucjpロケールを追加し、 $ locale -a で、ja_JP.eucjpロケールを用意できたのを確認し、 $ createdb -E EUC_JP -l ja_JP.eucjp -T template0 MyDB で、データベースを作成できた。 [参考] Ubuntuでja_JP.EUC-JPを使用する - World Wide Wonderful http://d.hatena.ne.jp/orangehat/20090421 ロケール(国際化と地域化) — Let's Postgres http://lets.postgresql.jp/documents/technical/text-processing/2/
2013年12月17日火曜日
Debian wheezy ：postgresql (9.1) で EUC-JP エンコードのデータベースを作成
2013年10月3日木曜日
Linux ソフトウェア RAID1の障害復旧記録(Ubuntu12.04)
おおよそ、以下の環境での記録です。 ・ubuntu 12.04 (ブートローダはGRUB2) ・/dev/sdOK のHDDは正常 ・/dev/sdFAILED のHDDは不具合 ・/dev/sdNEW は新規・新品HDD ・sdOK sdFAILED sdNEWは、全て同じ容量、同じパーティション構成 ・/dev/md0は sdOK1 と sdFAILED1 で構成 ・/dev/md1は sdOK2 と sdFAILED2 で構成 まず、データのバックアップをとった。 下の[復旧作業]を他の(仮想)PCで予行演習し、自己責任で作業を実行した。 [役立ちそうな情報確認・表示コマンド] RAIDの状態を表示 # cat /proc/mdstat /dev/sdX の製品名・シリアル番号・容量等を表示 (要 smartmontools パッケージ) # smartctl -i /dev/sdX /dev/sdX のパーティション情報をs(sector)単位で表示 # parted /dev/sdX unit s print [復旧作業] sdFAILED が Fail(F)状態ではない場合、Fail状態に変更。 # mdadm --manage /dev/md0 --fail /dev/sdFAILED1 # mdadm --manage /dev/md1 --fail /dev/sdFAILED2 sdFAILEDをRAIDから除去。 # mdadm --manage /dev/md0 --remove /dev/sdFAILED1 # mdadm --manage /dev/md1 --remove /dev/sdFAILED2 sdOKにGRUBが入っているか確認。 # dpkg-reconfigure grub-pc sdOK,sdFAILED の仕様を確認し、後の作業での取り間違えを回避。 # smartctl -i /dev/sdOK # smartctl -i /dev/sdFAILED PCをシャットダウン、sdFAILEDを除去、sdNEW を接続、PCを起動。 自分の環境では、/etc/grub/defaultの GRUB_TERMINAL=console これを無効に(コメントに)していた事などから、 GRUBのブートメニューでrecovery modeを選択しないと、 degraded状態でのUbuntu起動ができなかった。 とりあえず起動できたので、普通にlogin。 sdOK sdNEW が /dev/sda か /dev/sdb か、何なのかを確認、特定。 (あるいは /dev/disk/by-id/ とかを使えば良いのかもしれない) # ls /dev/sd? # smartctl -i /dev/sda # smartctl -i /dev/sdb # cat /proc/mdstat sdOKのパーティション情報を表示。 # parted /dev/sdOK unit s print /dev/sdNEW のパーティションを以下の条件で作成。 ・パーティションテーブルはMBR(GPTではない) ・パーティション1: 基本(primary)パーティション Start 2048s End 999423s ・パーティション2: 基本(primary)パーティション Start 999424s End 1953523711s ・パーティション1、2は、ともにLinux ソフトウェア raid 用 # parted /dev/sdNEW (parted) unit s (parted) print (parted) mklabel msdos (parted) print (parted) mkpart primary 2048s 999423s (parted) print (parted) mkpart primary 999424s 1953523711s (parted) print (parted) set 1 raid on (parted) set 2 raid on (parted) print (parted) quit /dev/sdNEWをRAIDに追加。 # mdadm --manage /dev/md0 --add /dev/sdNEW1 # mdadm --manage /dev/md1 --add /dev/sdNEW2 RAIDの状態表示で、追加作業の開始を確認し、完了するまで放置。 # cat /proc/mdstat 念のため、initrdを更新。要らないかもしれないが、なんとなく。 # update-initramfs -u GRUBを/dev/sdOK と /dev/sdNEWに(再)インストール。 # dpkg-reconfigure grub-pc PCを再起動し、RAID1障害復旧の完了を確認。 [参考] ソフトウェアRAID１障害時のHDD交換（Parted編） | クラウド備忘録 http://www.cloud-memo.com/2013/04/raidhddparted.html Ubuntu Manpage: GNU Parted - a partition manipulation program http://manpages.ubuntu.com/manpages/precise/man8/parted.8.html [おまけ作業：RAID1 --raid-devices=3] HDD2台(2重)構成のRAID1では、なんとなく心配になってきたので、 HDD(/dev/sdTHIRD)を追加し、HDD3台(3重)構成のRAID1に変更した。 パーティションを作成するところまでは sdNEWと同じなので省略。 spareとしてsdTHIRDを登録。 # mdadm --manage /dev/md0 --add /dev/sdTHIRD1 # mdadm --manage /dev/md1 --add /dev/sdTHIRD2 3台構成に変更。 # mdadm --grow /dev/md0 --raid-devices=3 # mdadm --grow /dev/md1 --raid-devices=3 RAIDの状態表示で、追加作業の開始を確認し、完了するまで放置。 # cat /proc/mdstat initrdの更新と、GRUBをsdTHIRDにもインストール。 # update-initramfs -u # dpkg-reconfigure grub-pc 以上で完了。 ちなみに、2台に戻す場合のmdadm処理は、以下の要領。 # mdadm --manage /dev/md0 --fail /dev/sdTHIRD1 # mdadm --manage /dev/md0 --remove /dev/sdTHIRD1 # mdadm --grow /dev/md0 --raid-devices=2 [おまけ：気になった点] 「initrd.img の更新は必要なのか？」 と思ったが、今回の作業では不要だったかもしれない。 UUIDの変化は、blkid コマンドにて、以下の通りいくつか確認した。 ・構成ディスクが変わっただけなので、md0 md1 のUUIDは変化無し ・sdFAILED[12] と sdNEW[12] のUUIDは同じなので、実質的にUUIDの変化無し ・sdFAILED[12] と sdNEW[12] のUUID_SUBは異なるので、UUID_SUBは変化あり ・mdadm.confには、UUID_SUBの記述は見当たらない ・ついでに、grub.cfgには、UUID_SUBの記述は見当たらない よって、更新は要らないかもしれない。ただし、 # update-initramfs -u # dpkg-reconfigure grub-pc このあたりの処理で、UUID_SUBを検出して利用している可能性はあるので、 これらを実行しておいたほうが無難だとは思う。 Linux ソフトウェア RAID1の障害復旧作業では起こらないかもしれないが、 何らかの理由か、何か別の処理で /dev/md や /dev/sd の UUIDが変われば、 設定の更新処理をしてからGRUBのインストールやinitrd.imgの更新等が必ず必要になるだろう。 処理内容は、おそらく以下のような感じ。※これは予想※ # echo mdを構成するsdのUUIDが変更されたら・・・ # cd /etc/mdadm # mv -i mdadm.conf mdadm.conf--backup # /usr/share/mdadm/mkconf generate # # echo mdのUUIDが変更されたら・・・ # cd /etc # mv -i fstab fstab--backup # vi fstab # # update-initramfs -u # dpkg-reconfigure grub-pc [おまけ:発見したこと] Ubuntu新規インストール時にRAIDの作成処理をした後ぐらいの所で、 「OSブート時、もしもRAIDがdegrade状態だった場合の通常処理は、 そのまま起動か？中止か？」 という選択を求められたが、その変更方法が気になっていた。 # dpkg-reconfigure mdadm これで、変更できるっぽい事を知った。
登録:
投稿 (Atom)