PostgreSQLのversion up
PostgreSQLのversion upを実施した時のメモです。
移行前 version : 9.3.1
移行後 version : 9.5.10
version upすることになった経緯
AWSのEC2上で動作していたDBサーバをRDS上へ移して管理を楽にしたいということがありました。
DMS(Database Migration Service)を利用して移行しようとしましたが、DMSがサポートしているPostgreSQLのversionは9.4以降のため使用できないということが発覚。
そのため、一旦versionを上げてから移行する方針となりました。
9.3系のサポートも2018年9月で切れるということもあり。
実際にやったこと
EC2上のDBインスタンスを完全に停止させて、AMIを取得
取得したAMIから新規にDBインスンタスを作成
事前に作成しておいたコマンドを投下
9.3.1で動作しているPostgreSQLの停止して、バックアップとして避けておく。
sudo /etc/init.d/postgresql stop sudo yum -y update sudo mv /usr/local/pgsql /usr/local/pgsql.old
今回はソースコードからインストールするためPostgreSQLの公式サイトからインストールしたいバージョンを取得。
sslをサポートさせるために--with-opensslオプションをつけておく。
あとは通常のmake installを実施。
cd /usr/local/src sudo wget https://ftp.postgresql.org/pub/source/v9.5.10/postgresql-9.5.10.tar.gz sudo tar zxvf postgresql-9.5.10.tar.gz cd postgresql-9.5.10 ./configure --with-openssl make make check sudo make install
物理ファイル保存用のディレクトリを作成。
postgresユーザに変更してpg_upgradeを実行。
シンボリックリンクで切り替えを行ったため短時間で終わります。
sudo mkdir /usr/local/pgsql/data sudo chown postgres:root /usr/local/pgsql/data sudo chmod 700 /usr/local/pgsql/data sudo su - su - postgres export PGDATA=/usr/local/pgsql/data /usr/local/pgsql/bin/initdb -d /usr/local/pgsql/data /usr/local/pgsql/bin/pg_upgrade -b /usr/local/pgsql.old/bin -B /usr/local/pgsql/bin -d /usr/local/pgsql.old/data -D /usr/local/pgsql/data -k
9.3.1で使用していたpg_hba.confとpostgresql.confはそのまま流用しました。
mv /usr/local/pgsql/data/pg_hba.conf /usr/local/pgsql/data/pg_hba.conf.org mv /usr/local/pgsql/data/postgresql.conf /usr/local/pgsql/data/postgresql.conf.org cp -ip /usr/local/pgsql.old/data/pg_hba.conf /usr/local/pgsql/data/pg_hba.conf cp -ip /usr/local/pgsql.old/data/postgresql.conf /usr/local/pgsql/data/postgresql.conf ./analyze_new_cluster.sh
ついでにslave作ったりと色々足りてなかったことも追加で実施しました。
参考
PostgreSQL 9.5.4文書
PostgreSQL9.4 から PostgreSQL9.5 に pg_upgrade する - Qiita
他ドメインからELBへのルーティング方法
概要
他のサービスでドメインを管理されていたけれど、AWSと併用して使うことになりその移行を実施したのでまとめました。
ELBとWEBサーバ間はひとまずHTTPで通信させるもとのとする。
ドメイン例
移行前：www.hogehoge.com
移行後：www.tk-sugar.com
やったこと
- CNAMEの設定
- 証明証の差し替え
- nginx.confの書き換え
CNAMEの設定
元々使用していたドメイン管理サービスでDNSレコードの追加を実施。
www.hogehoge.comに対してレコードを設定する。
レコードの登録が完了しwww.hogehoge.comへアクセスするとwww.tk-sugar.comへルーティングされるようになる。
イメージはこんな感じ
| ホスト名 | 種別 | 内容 |
|---|---|---|
| www.hogehoge.com | CNAME | www.tk-sugar.com |
証明証の入れ替え
元々リバースプロキシに設定されてあった証明書をCertificate Managerから登録。
本来は新規にELBを立てたり、Route53を設定しなければならないが、今回は既存で存在していたものを流用する形で設定する。
(実際は少し設定変えたりしましたが、今回は割愛)
また、中間証明書が設定されていた場合は証明書チェーンを設定してやらないとうまくインポートできません。
証明証の登録完了後、該当するELBの443ポートに対して証明書を割り当てます。
※ ELBから振り分けさせたサーバをターゲットさせておくことも忘れずに
あとはhttps通信でアクセスできるか確認しましょう。
nginx.confの書き換え
メンテナンスページの出力用設定
maintainance.htmが存在するなら503を返してメンテナンスページを表示するだけの簡単な仕組みです。
それ以外なら自分で設定したページが出力されます。
メンテナスページとの切り替えは
mv maintainance.htm maintainance.html
などで簡単に実施できます。
server {
listen 80;
省略
error_page 500 501 502 503 504 /var/www/html/error/maintainance.htm;
set $maintenance false;
if ( -f /var/www/html/error/maintainance.htm) {
set $maintenance true;
}
location / {
if ($maintenance = true) {
return 503;
}
proxy_pass http://localhost/;
proxy_redirect default;
}
参考URL
【初心者向け】ELBにSSL証明書をインストールする ｜ Developers.IO
SSL Termination(ELB)でアプリ(EC2)がHTTPSのチェックを行えない場合 | cloudpack.media
Nginxでメンテナンスページに編集なしで即時切り替える方法 - Qiita
MongoDB 使い方
MongoDBとは
NoSQLと言われているデータ管理ツールです。
コマンドとか
SELECT * FROM hoge_table;
MongoDB
db.hoges.find()
正規表現
「/」（スラッシュ）を使いたい場合
db.getCollection('pages').find({path :{$regex:"tksugar/hogehoge")
dumpとresotre
hogehogeDB SCPやCyberduckを利用するとサーバ間でdumpファイルを簡単に移動ができます。
mongodump --host localhost --db hogehoge
mongorestore -v --db crowi dump/hogehoge
使い方さえわかれば意外と単純です。
PostgreSQL pg_dump
テーブル単位でのdumpのとり方についてまとめていきます。
productionとlocalで同期させるいい方法はないものか・・・
依存関係があまり無いテーブルのリストア方法
テーブル単位のバックアップ
例)
DB名 ：fugaDB
テーブル名：user_xxxxxx
ロール名 ：hogehoge
サーバIP ：54.209.XX.XX
pg_dump -v -h 54.209.XX.XX -d fugaDB -U hogehoge -W -t user_xxxxxx > user_xxxxxx.dump
output file : user_xxxxxx.dump
各種オプション
- -h：ホスト名
- -d：データベース名
- -U：ユーザ名
- -W：パスフレーズ省略
- -t：テーブル名
テーブルの復元
取得したテーブルをlocalにrestoreするためにまずlocalのテーブルを削除します。
psqlコマンドでfugaDBを指定してログインします。
その後SQLを発行します。
DROP TABLE hogehoge;
テーブルの削除が完了後、psqlコマンドでデータベース名とアウトプットしたdumpファイルを指定して実行します。
psql -d hogehoge -f user_xxxxxx.dump
依存関係が複雑ではなければこれで問題ないはず・・
複数のテーブルを扱っていて更新頻度が高くい場合などシェルスクリプトにまとめて実行すると楽です。
awsとかsshとか
結構期間が空いてしまいましたが、久しぶりに更新しにきました。
今まで使ったことのなかったAWSを仕事で使うようになったので色々まとめていきます。
改めてAWSの種類が多いと困惑しながらも、実際に触るようになったサービス
使ってるAWSサービス
- EC2 Amazon Elastic Compute Cloud
- production、develop、test環境を各サービスごとに設置
- S3 Amazon Simple Storage Service
- データをバケットごとに設置
- RDS Amazon Relational Database Service
- サービスによってはEC2でDBサーバを建てずこちらを使用
- IAM AWS Identity and Access Management
などメジャーなものばかり使用しています。
その他にも今までネットワークが畑だったので色々新鮮です。
SSH config
Host xxx_production HostName xx.yy.zz.0 user hogehoge port xxxx identityfile ~/.ssh/xxxx/xxxxxxxx.pem ServerAliveInterval 60
ネットワーク機器でのSSHはよくやっていたのですが、UnixからのSSHはあまりやったことがなかったのでまとめてみました。
基本的にconfigに記述しているのは上記の項目です。
- Host : 任意の接続名(好きなもので)
- HostName : Public DNSかPublic IP
- user : サーバのログインユーザ(default ec2-user)
- port : SSH接続用ポート番号(default 22)
- identityfile : サーバ接続用の秘密鍵あるPATHを指定
- ServerAliveInterval : Keep Aliveの指定(60秒ごとに生きていることをサーバへ報告)
だいたいこんな感じで設定しています。
一つのファイルに複数の接続先が書けますし、他にも色々とオプションがあるので気になった方はぜひ試してみてください。
とりあえず、今回は以上
Rails PostgreSQL
Multicolumn(複合インデックス)を作成した時のこと
環境
設定
migrationファイルに以下を記述
add_index :xxxxxxxxxxx_xxxxxxx, [:xxxxxxxx_id, :xxxxxxxxxx_id]
Railsでよくあるindexの追記設定です。
記述後のmigrate
bundle exec rake db:migrate:up VERSION=xxxxxxxxxxxxxxxxxxxxxxxxx
上記コマンドでrailsのmigrateを実行
特にエラーも出力されず、無事にmigrationが完了
indexが無事にできているか確認
SELECT tablename, indexname FROM pg_indexes;
select * from pg_indexes where indexname = 'インデックス名';
上記コマンドを実施しても追加したはずのindexが表示されず…
解決方法
検索しても事例が出てこなく、色々試していくうちに…
PostgreSQlの識別子の長さは63バイトまでと判明(ｴｪ…
実際に自動生成される文字数を数えて見るとオーバーしてました。
https://www.postgresql.jp/document/9.2/html/sql-syntax-lexical.html
今回はたまたまテーブル名とカラム名が長くうまく生成されなかったみたいです。
migrate実行時にエラー出すとかこけて欲しかった。
オプションで:nameを指定して63バイト以内に指定しましょう。
