忍者ブログ
Admin / Write / Res
ちゃんとカテゴリ分けされておりませんので、 記事をお探しならブログ内検索が便利です。 ご活用くださいませー+.(≧∀≦)゚+.゚
ブログ内検索
カレンダー
02 2024/03 04
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
カウンター
アクセスカウンター
最新コメント
[03/26 Tonaldcet]
[01/16 jilibet]
[10/20 Call Girl in Delhi]
[09/07 לפרטים נוספים]
[08/14 nuevos casinos online 2022]
最新トラックバック
プロフィール
+ハンドル+
y_ayamori(purple)
+職業+
IT系エンジニア
+すまい+
さいたま
バーコード
[1]  [2]  [3]  [4]  [5]  [6]  [7]  [8]  [9]  [10
あるプロジェクトでsqlite3を使用してみようとおもって、導入したはいいものの
想定より、並列作業が発生したり、管理レコード数が伸びてしまい、パフォーマンスが
発揮できなかったのでMySQLへ移行しようと思いました。

その際、SQLの違いでスムーズにリストアがいかなかったので
あれこれこねくり回してしまった結果のメモです。

 db_file=sqlite.dmp
 grep -v 'PRAGMA' ${db_file} > ${db_file}.tmp; cat ${db_file}.tmp > ${db_file}
 sed -e 's/TRANSACTION//g' ${db_file} > ${db_file}.tmp; cat ${db_file}.tmp > ${db_file}
 sed -e 's/"//' ${db_file} > ${db_file}.tmp; cat ${db_file}.tmp > ${db_file}
 sed -e 's/"//' ${db_file} > ${db_file}.tmp; cat ${db_file}.tmp > ${db_file}
 sed -e 's/AUTOINCREMENT/AUTO_INCREMENT/' ${db_file} > ${db_file}.tmp; cat ${db_file}.tmp > ${db_file}
 grep -v 'sqlite_sequence' ${db_file} > ${db_file}.tmp; cat ${db_file}.tmp > ${db_file}
 grep -v 'CREATE INDEX' ${db_file} > ${db_file}.tmp; cat ${db_file}.tmp > ${db_file}
 rm ${db_file}.tmp
INDEXは無視です。
形式が違うので、こちらは必要に応じて後から手動で追加です。
そのほか、sqlite3は主に、INTとTEXTなので、場合によってはvarchar()にしたほうがいいと思います。
取り急ぎ、MySQLへ持ってきたかったので、かなり雑です。
テーブル構造によってはもっと複雑になるでしょう。
その時に直面したらまたUPDATEします。

拍手

PR
ウィンドウズでハングアップしているバッチを停止しなくてはならない事案が発生しました。。。
ウィンドウズは正直苦手なのよね…
とはいえ、WindowsServer2003の構築経験があるので、この手の話はそう拒否るほどじゃないのがワ・タ・シ ←
最近PythonばかりなのでここでもPythonを使ってみることにします。
と、ここまで来てやっぱり不要という話になってしまったので、プロセスの確認までを備忘録的にあげておきます。


import subprocess
import csv
p = subprocess.Popen(
    ['TASKLIST',
    '/S',
    'remote-pc',
    '/U',
    'administrator',
    '/P',
    'pasword',
    # '/NH',
    '/FO',
    'CSV',
    '/V',
    '/FI',
    'CPUTIME lt 00:05:00',
    #'/FI',
    #'USERNAME eq administrator',
    '/FI',
    'IMAGENAME eq my_batch.bat'],
    stdout=subprocess.PIPE)
reader = csv.reader(p.stdout)
header = reader.next()
for row in reader:
    for i in xrange(len(row)):
        print header[i].rjust(25), row[i]
    print "-" * 60

p.stdout.close()

確認環境
Windows7 6.1.7601 Service Pack 1 ビルド 7601
Python2.7.6

拍手

WEB+DB PRESSという書籍を社内で購読しているのですが、
そこにPHPの実行環境を切り替える記事がありまして、
エンジニアの一人が導入できないって?っていうから
トライしてみました。

便利は便利なんですけど、これはネックになるかな?って思ったのが
  1. ApacheのLoadModuleを逐一手動で切り替える必要がある
  2. phpbrew自体PHPでできている
1.はconf.dなどで切り出して差し替えるなどしてほしかったなー★
モジュール先をシンボリックにしても大丈夫そうなのに…
2.はきついですね。。。
システム要件にphp5.3とあるので、5.3がデフォルトで入る環境でないと
結局自分でphpをコンパイルして導入することになるので、
その程度の知識があればphpbrewなんかなくても運用できそうだし、、、
phpbew自体がPHPってことはphpbrewでphpを切り替えると、
切り替えた後のPHPでphpbrewを動作させることになるので、
ドツボにはまることがあります。
※たとえば --oldオプションなどでphp5.1.6とか導入した場合
個人の意見としてはすごいナンセンスだと思います。。。

なにはともあれ、下記に導入した手順を載せておきまーす
# apache & mysql は導入済みが前提
# もし新規のサーバに入れるなら下記コマンドを実行するの
yum -y install httpd httpd-devel mysql mysql-server mysql-devel

# 依存パッケージのインストール
# 切り替えに使用するPHPはコンパイルして導入するみたいなので
# コンパイルに必要なモジュールをインストールしておきます
yum -y install gcc gcc-c++
yum -y install libxml2-devel
yum -y install bzip2-devel
yum -y install openssl-devel
yum -y install readline-devel
yum -y install libxslt libxslt-devel
yum -y install bison
yum -y install libtool-ltdl-devel
yum -y install libicu-devel
yum -y install flex
yum -y install patch
rpm -Uvh 'http://elders.princeton.edu/data/puias/unsupported/6/x86_64/libmcrypt-2.5.8-9.puias6.x86_64.rpm'
rpm -Uvh 'http://elders.princeton.edu/data/puias/unsupported/6/x86_64/libmcrypt-devel-2.5.8-9.puias6.x86_64.rpm'
rpm -Uvh 'http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/mhash-0.9.9-1.el6.rf.x86_64.rpm'
rpm -Uvh 'http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/mhash-devel-0.9.9-1.el6.rf.x86_64.rpm'

# wget のインストール
# 本家手順ではcurlを使用しているのですが、なぜかダウンロードができないので…
yum -y install wget
cd /usr/local/src

# PHP5.3に依存するみたい
# https://github.com/c9s/phpbrew/wiki/Requirement
# なのでここで5.3を入れてしまいましょう
cd /usr/local/src
test -f ./php-5.3.28.tar.gz || \
  wget 'http://jp1.php.net/get/php-5.3.28.tar.gz/from/this/mirror' -O ./php-5.3.28.tar.gz
test -d ./php-5.3.28 && \rm -rf ./php-5.3.28
tar zxf php-5.3.28.tar.gz
cd php-5.3.28
./configure \
  --prefix=/usr/local/php \
  --with-zlib \
  && \
  make -j2 && \
  make install
export PATH="${PATH}:/usr/local/php/bin"
# ==> PHP 5.3.28 (cli)
php -v 

# phpbrew のインストール
cd /usr/local/src
test -f phpbrew || \
  wget 'https://raw.github.com/c9s/phpbrew/master/phpbrew'
\cp ./phpbrew /usr/local/bin/phpbrew
chmod +x /usr/local/bin/phpbrew

# phpbrewの初期設定
/usr/local/php/bin/php /usr/local/bin/phpbrew init
if grep -q 'source ~/.phpbrew/bashrc' ~/.bashrc
then
  echo 'skip'
else
  echo 'source ~/.phpbrew/bashrc' >> ~/.bashrc
  echo 'export PATH="${PATH}:/usr/local/php/bin"' >> ~/.bashrc
  source ~/.bashrc
fi

# インストールできるphpのバージョン一覧
phpbrew known
# コンパイルオプションの一覧
phpbrew variants

# 複数バージョンのインストール
phpbrew install 5.5.12 +default +mysql +mb +ftp +apxs2
phpbrew install 5.4.28 +default +mysql +mb +ftp +apxs2
phpbrew install 5.3.27 +default +mysql +mb +ftp +apxs2 +intl


# 異なるバージョンへの切り替え
phpbrew switch php-5.5.12
php -v
phpbrew switch php-5.4.28
php -v
phpbrew switch php-5.3.27
php -v

# 切り替え環境の終了(元のPHPに戻る)
/usr/local/php/bin/php /usr/local/bin/phpbrew switch-off


# アンインストーる
\rm -rf ~/.phpbrew
\rm -f /usr/local/bin/phpbrew
実行環境
Scientific Linux6.4 (minimal)

参考サイト
https://github.com/c9s/phpbrew
https://github.com/c9s/phpbrew/issues/167
http://blog.mktime.com/archive/290.html
http://d.hatena.ne.jp/donbulinux/20091217/1261049589
http://hack.aipo.com/archives/324/
http://www.stuartmacfarlane.co.uk/configure-error-unable-to-detect-icu-prefix-or-no-failed-please-verify-icu-install-prefix-and-make-sure-icu-config-works

拍手

あたしとしては珍しくsqlite3を使ってみようと思い立ったのですb
Windows環境だし、そんなに複雑なトランザクションも必要ないし、ってところでー♪

と息巻いてみたもののいきなりエラーにあたる…

OperationalError: unable to open database file

なぜに開けなし!! <( ̄□ ̄;)>
ググっても、パスが間違っているか、書き込み権限系ばかり。。。
さんざん迷いに迷って、たどり着いたのが…
パスにマルチバイトを含んでいたからでした。。。
非常にお粗末・・・ぐぅ

と、いうことで
sqlite3.connect() の引数はユニコードで渡そうねって話でした。

実行環境
Windows7 6.1.7601 Service Pack 1 ビルド 7601
sqlite3 2.6.0
Python2.7.3

参考サイト
http://d.hatena.ne.jp/dayflower/20070123/1169546863
http://php-sql-gdgd.jugem.jp/?eid=60

拍手

pg_dumpの分割 でも触れましたが、DBのダンプファイルをダンプの時点で分割しておかないとリストアの時結構大変です。
それでも1ファイルでダンプしちゃったなら、前述の方法などで分割するしかないですが、できることならダンプの時点でテーブルごとに分かれているのが理想です。
pg_dumpのオプションでなんとかなればいいのですが、3流エンジニアにはドキュメントを理解する能力がありませんでした。。。
ということで仕方ないので、例によってpythonスクリプトでダンプするためのShellスクリプトを作成し、実行することでテーブルごとにダンプファイルを作成するための簡単なものを作成しました。


python

db_name = 'db_name' 
output_path = './db_dump'
gzip = False

import subprocess
import os
os.mkdir(output_path)

if gzip:
  out_cmd = 'gzip --best -c'
  ext = '.dmp.gz'
else:
  out_cmd = 'cat'
  ext = '.dmp'

cmd = ['echo', r'\dt']
sp = subprocess.Popen(cmd, stdout=subprocess.PIPE)
cmd = ['psql', db_name, '-t']
tp = subprocess.Popen(cmd, stdin=sp.stdout, stdout=subprocess.PIPE)

open('pg_dump.sh', 'wb').write('') # initialyze
for line in tp.stdout:
  if not line.strip():  continue
  table_name = line.split('|')[1].strip()
  cmd_line = 'pg_dump {0} -t {2} | {3} > {1}/{0}_{2}{4}\n'.format(
                                                              db_name,
                                                              output_path,
                                                              table_name,
                                                              out_cmd,
                                                              ext
                                                            )
  open('pg_dump.sh', 'ab').write(cmd_line)

exit()

# The shell script from here.
sh -x ./pg_dump.sh

確認環境
Python 2.7.3
PostgreSQL 9.3.0

検索タグ
python, postgresql

拍手

またまた唐突にtorをインストールしてくれと言われました。。。
会社として本当にそんなツールを使うのだったら、ダメだと思うの。。。
まぁ、用途は(あたしは)きいてませんしー
聞かない聞かない
見なかったことにするのはこの業界で生き残る技術よ♡

rpm -qi wget || \
  yum -y install wget
rpm -qi automake || \
  yum -y install automake
rpm -qi make || \
  yum -y install make
rpm -qi gcc-c++ || \
  yum -y install gcc-c++
rpm -qi libevent-devel || \
  yum -y install libevent-devel
rpm -qi openssl-devel || \
  yum -y install openssl-devel
rpm -qi php || \
  yum -y install php

cd /tmp
test -f tor.tgz ||
wget 'https://gitweb.torproject.org/tor.git/snapshot/c0441cca8b483882f5676b98081f0fe4b52d3ae1.tar.gz' -O tor.tgz 
tar zxf tor.tgz
cd tor-*/

./autogen.sh && \
./configure --prefix=/usr/local/tor --disable-asciidoc && \
make clean && \
make -j2 && \
make install

mkdir -p /usr/local/tor/var/{log,tmp,run}

php -r ' 
$conf = "";
$ip = "0.0.0.0";
$conf .= sprintf("SocksPort %s:9100\n", $ip);
$conf .= "Log notice file /usr/local/tor/var/log/notices.log\n";
file_get_contents("/usr/local/tor/etc/torrc", $conf);
'

# 起動
cd /usr/local/tor/var/tmp
nohup /usr/local/tor/bin/tor -f /usr/local/tor/etc/torrc &
_pid=$!
cd /usr/local/tor/var/run
echo -n ${_pid} > tor.pid

# 停止
cat /usr/local/tor/var/run/tor.pid | xargs kill

# 確認
php -r ' 
$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL, "http://taruo.net/e/");
curl_setopt ($ch, CURLOPT_TIMEOUT, 60);
curl_setopt ($ch, CURLOPT_PROXY, "127.0.0.1:9100");
curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt ($ch, CURLOPT_FAILONERROR, true);
curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, 1);
$result = curl_exec($ch);
print curl_errno ($ch);
print strip_tags($result);
curl_close ($ch); 
' | grep -A1 -e REMOTE_HOST -e REMOTE_ADDR

さんざんPHPとかねじ込んできた割に、最後はgrepというのがあたしらしいわねー
でわでわ

拍手

Linux上で作業していた時に表計算ソフトからDBにつなげたらいいなーって思ったら案外簡単にできるようでした。

http://superuser.com/questions/391242/how-do-i-connect-to-a-postgresql-server-using-libreoffice-base

今回はPostgreSQLの場合です。

Version
Calc:4.2.0.4 (en version)
Postgres: 9.2.4(source compile)

拍手

完全によそ様の引用です ( ̄▽ ̄;)
Python2.7.3で確認済み

colors = {
    'clear': '\033[0m',
    'black': '\033[30m',
    'red': '\033[31m',
    'green': '\033[32m',
    'yellow': '\033[33m',
    'blue': '\033[34m',
    'purple': '\033[35m',
    'cyan': '\033[36m',
    'white': '\033[37m'
}
for k, v in colors.iteritems():
    print '%s%s' % (v, k)

参考元:
http://d.hatena.ne.jp/heavenshell/20090909/1252509749

拍手

MySQLの場合、MASTER側でエラーが起きるようなSQLを発行してもSLAVE側にそのSQLが流れてしまう場合があり、SLAVEで実行した際に同じようにエラーになり、止まってしまうことがあるようです。
原因は多々あると思いますが、現在止まっているSQLを無視して問題ないと判断できる場合はそのSQLの実行をスキップして次に進めることができるみたいです。
その対処方法の備忘録です。

-- 現在のSLAVEの稼働状況を確認
SHOW SLAVE STATUS \G
-- 厳密には停止の必要はないけれどここではSLAVEの機能そのものをいったん再起動します
STOP SLAVE;
-- 現在出ているエラーをスキップします
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
-- SLAVE(レプリケーション)を再開します
START SLAVE ;
-- 少し待ちます
SELECT SLEEP(2);
-- 再度SLAVEの稼働状況を確認します
SHOW SLAVE STATUS \G

拍手

postgresql は普段あまり使わないDBなのでついついスキーマ変更用のSQLを忘れてしまいますね。゚・(>Д<)・゚。

ということで備忘録。
postgresql 9.2 の場合です。
8とか7はおそらく違います。


ALTER TABLE table_name ALTER COLUMN column_name
  SET
    DATA TYPE data_type;


table_name:  対象のテーブル名
column_name: スキーマ変更対象のカラム名
data_type: 新しいスキーマ
 ex.)
 varchar(255)
 bigint


http://www.postgresql.jp/document/9.2/html/sql-altertable.html


14.10.27 追記
スキーマ長を増やすだけ(型は変えずに長さだけ変える場合)とは違い、型そのものを変更する場合は失敗する場合が多々あります。
例えば元のカラムがvarchar(10)で、integer(10)に変更を試みようとした場合でも、カラムの中には一見数字しか見えなくても型変換に失敗し、変更できないことがあります。
その場合はUSINGを使用して、元のデータと後のデータを指定してあげることで解決が可能です。
例を記載します。

ALTER TABLE table_name ALTER COLUMN available 
SET
  DATA TYPE BOOLEAN
    USING CASE
      WHEN available = 1
      THEN TRUE
      WHEN available = 2
      THEN FALSE
      END;



それでも失敗する場合は、INDEXをいったん削除しましょう。

拍手

Copyright ©  アナログを愛するデジタル生活館 All Rights Reserved.
* material by Pearl Box   * Template by tsukika

忍者ブログ [PR]