気ままNote

個人の技術メモ

TRUNCATE したらシーケンスもリセットさせる

PostgreSQL を使っていてテストデータを入れ直したいときに TRUNCATE でテーブルに保存したデータを消していました。
再度データを挿入したときにシーケンスが以前の番号を保持したままになってしまったので、リセットする方法を調べました。

公式ドキュメントに載っていた内容のままですが、TRUNCATE のあとにRESTART IDENTITY を追加すればいいようです。

TRUNCATE bigtable, fattable RESTART IDENTITY;

参考

TRUNCATE

無線が切れるので「恐竜ミニゲーム」やってる

やりすぎて目が痛くなってきたからやめた。 だいたい安定して4桁スコアが出るようになってくると飽きてくる。 クッキーの生産してたときも同じくらいでやめた気がする。

オフィスの無線が切れるのは仕方がないにしても、そのままコンビニが適当に飛ばしてるwifiに自動で繋がりに行くのは危ない。 オフィスが変わるたびにこの設定しないようにしたい。

tmuxの設定を整理した

思い出したようにtmux の整理をしていたら昔設定した内容を忘れていたので備忘録として残しておく。

prefix-keyの変更

C-x 派

# prefix
unbind-key C-b
set -g prefix 'C-x'
bind-key 'C-x' send-prefix

設定のリロード

[prefix-key] r

pane内でスクロール

スクロールモード
[prefix-key] [
fn + ↑↓

各ペインの同期操作

:set-window-option synchronize-panes on

キーバインド設定で省略可能

bind e setw synchronize-panes on
bind E setw synchronize-panes off

プラグイン周り

いつ導入したか思い出せないが、tmux-plugins/tpm を利用していた。
[prefix-key] Iでインストールを実行する

set -g @tpm_plugins " \
    tmux-plugins/tpm \
    tmux-plugins/tmux-sidebar \
    tmux-plugins/tmux-copycat \
    tmux-plugins/tmux-open \
    tmux-plugins/tmux-resurrect \
    tmux-yank/tmux-yank \
    tmux-plugins/tmux-battery \
    tmux-plugins/tmux-online-status \
"
# tmux-resurrect
set -g @resurrect-save 'S'
set -g @resurrect-restore 'R'

# Initialize tpm
run-shell ~/.tmux/plugins/tpm/tpm

Vue.jsをif-elseifのように扱う方法

http://cdn-ak.f.st-hatena.com/images/fotolife/i/ie-kau/20150818/20150818232251.png

Vue.js1.0.0

Vue.jsを利用したての頃、複数の条件分岐を求められた際に悩んだことがあります。
例えば、セレクトボックスで選択されたアイテムにごとに表示内容を切り替えたい場合です。

通常LL言語であればif文・elseif文で複数の条件式を組み合わせられますが、Vue.jsのドキュメントを見る限りそのような記法はありませんでした。

対策

そのときは選択肢が少なかったこともあり、
v-modelとvalueを直接指定して条件分岐させました。

var demo = new Vue({
    el: '#demo',
    data: {
        selectItem: null
    }
});
<select v-model="selectItem">
      <option value="aaa">AAA</option>
      <option value="bbb">BBB</option>
      <option value="ccc">CCC</option>
</select>

<div v-if="selectItem === 'aaa'"></div>
<div v-if="selectItem === 'bbb'"></div>
<div v-if="selectItem === 'ccc'"></div>

さらに複雑な条件が求められればこの方法では苦しくなるでしょうが、
手軽に進めたいときは今でもこの方法を使っています。

LinuxでTCPのTIME_WAITコネクションを減らす

サーバーの負荷対策の一つとして、TCPコネクションの設定を修正した。

コネクション数の計測

[user01@web /]# netstat -pan | grep TIME_WAIT | wc -l

設定即時反映

  • echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
  • echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
  • sysctl -p

OSを再起動したときも変更値を適用する

  • /etc/sysctl.conf
# 追記
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

参考URL

zabbix clientのせいでTIME_WATEが大量に発生する件について | polidog lab++

Linux - ぜんぶTIME_WAITのせいだ! - Qiita

LinuxのTCPコネクション - ITメモ

geo-replicationのdebug設定

  • debugをONにする
# gluster volume geo-replication Volume1 ssh://User@example.com:gluster://localhost:Volume2 config log-level debug
# gluster volume geo-replication Volume1 ssh://User@example.com:gluster://localhost:Volume2 config gluster-log-level debug
  • debugをOFFにする
# gluster volume geo-replication Volume1 ssh://User@example.com:gluster://localhost:Volume2 config '!log-level'
# gluster volume geo-replication Volume1 ssh://User@example.com:gluster://localhost:Volume2 config '!gluster-log-level'

すぐ忘れそうになってしまうのでメモとしておいておきます。

PostgreSQLを9.3から9.5beta1へアップグレードした時のメモ

はじめに

PostgreSQLの9.5beta1が出たのでさっそく使って見るために環境を整えたときのメモ。
一年前ほど前にconohaのVPSPostgreSQLをインストールしていたのだけれど、
そのときのバージョンが9.3だったので、復習がてらそのままアップグレードすることにした。

8系とは違い、9系はコマンドも豊富になってきて簡単だった。

  • pg_upgrade
pg_upgrade -b oldbindir -B newbindir -d olddatadir -D newdatadir [option...]

公式ドキュメント

作業環境

OS 移行前 移行後
CentOS6.4 PostgreSQL9.3 PostgreSQL9.5beta1

PostgreSQLのインストールは省略

 方法

pg_upgradeコマンドを使って、9.3のデータ領域を9.5beta1に反映させる。動作チェックのために最初は「-c」をつけた。

/usr/pgsql-9.5/bin/pg_upgrade -c -b /usr/pgsql-9.3/bin/ -B /usr/pgsql-9.5/bin/ -d /var/lib/pgsql/9.3/data/ -D /var/lib/pgsql/9.5/data/

以下のメッセージが表示されてエラーとなった。
以前インストールしたときは「en_US」としていたようだ。

lc_collate values for database "postgres" do not match:  old "en_US.UTF-8", new "ja_JP.UTF-8"

envコマンドによると今の設定では確かに「ja_JP」となっていた。
今回は特にこだわりがないので「en_US」に設定を変更する。

sibukixxx:~$ env | grep LANG
LANG=ja_JP.UTF-8

sibukixxx:~$ export LANG=en_US.UTF-8

再び動作チェックをしたところ問題ないことがわかったので、
チェックオプション無しで実行。特に問題なくアップグレードができた。

Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* system OID user data types                ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for invalid "line" user columns                    ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows on the new cluster                        ok
Deleting files from new pg_clog                             ok
Copying old pg_clog to new server                           ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster
                                                            ok
Creating newly-required TOAST tables                        ok
Copying user relation files
                                                            ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

9.5beta1を起動後、動作確認をしつつanalyze_new_cluster.sh の実行をして終了。