RDS に3秒で引っ越す

mysql AWS RDS

便利ですね。aws。ほんと今更。


釣りです。

事前準備
  1. AWS のアカウントがあり、RDSでmysqlのインスタンスを立ち上げていること
    1. [Parameter Groups] log_bin_trust_function_creators = 1
  2. VPCのもろもろ(subnetやらルーティングやらACLやら)の設定は済んでいること
    1. セキュリティは気をつけて下さい
  3. 引越し元サーバからglobal経由でmysql@RDSに接続できること
    1. ポートフォワードでもなんでも繋がっていればOK
  4. 引越し元サーバのmysqlがそんなに容量を食ってないこと
 [引越し元サーバ] --( global )--> [RDS]
引越し元サーバにログイン

アプリの認可解除

facebook google oauth2 twitter

数年、開発から離れるとトレンドもすっかり変わって追いかけるのすごい大変。

ユーザが退会したら

SNSへの認可もAPIで取り消したいのが人情。
テストのべき等性も考えると不可避な事案でございますね。

とりあえずメジャーな twitter, facebook, google の解除APIを調べたのでリンクなどを残します。


twitter

.... と思ったら違う。
わからん。無いのか？？教えてえろい人。
幸先悪い。

facebook


google

Using OAuth 2.0 for Web Server Applications - Google Accounts — Google Developers

Revoking a token

In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting the following URL and explicitly revoking access: https://accounts.google.com/b/0/IssuedAuthSubTokens. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed.

To programmatically revoke a token, your application makes a request to https://accounts.google.com/o/oauth2/revoke and includes the token as a parameter:

curl https://accounts.google.com/o/oauth2/revoke?token={token}


twitter は 3〜4のウェブサービス側から連携解除したり、ウェブサービス自体から退会しても、認可情報が残ってる。

... ってか他のSNSも、残ってるの多いな。

あんまり気にしなくてよいのか？？

いや、ひょっとしたら非同期という線もありうる。
もうしばらく寝かしてみよう。
http://blog-imgs-43.fc2.com/a/b/s/absolutezero0808/216238_212856755409816_5467250_n.jpg

安物とメーカー製でどれほど違うというのか？

linux 
[user@host ~]$ checksignal ${BSちゃんねる}
device = /dev/pt1video0
C/N = 13.647913dB
...(snip)...

[user@host ~]$ checksignal ${ちでじ}
device = /dev/pt1video2
C/N = 29.912397dB
...(snip)...

[user@host ~]$ checksignal ${CSちゃんねる}
device = /dev/pt1video0
C/N = 16.236807dB
...(snip)...


さらっとwebを漁った感じ、どうやらこれは弱いっぽい。
いまだ pt1 なのも、ひとによっては m9(^q^) でしょうね。

電界強度とか受信感度みたいな、低レイヤに疎いのでなんともはや...。

これまでの数年は、六賀とか失敗してもあんまり気にしなかったけど、PCでリアルタイム視聴したい！との要求があり、マルチキャスト始めました的な感じで運用を開始したところ、何時間に一回かの割合でデコード失敗したよメッセージがでる。

daemon にして定期的に HUP 投げようかとも思ったけど、処置としては雑すぎるので一度環境を確認してみましょう。


現在 [サーバ] <---> [アンテナ] を繋いでいるのは

  • アキバで投げ売りされてた超低価格 && とぐろを巻く無駄に長いケーブル

これを

  • ヨドバシで適度な長さ && メーカ名の付いたケーブル

へ交換してみます。

[user@host ~]$ checksignal ${BSちゃんねる}
device = /dev/pt1video0
C/N = 13.987986dB
...(snip)...

[user@host ~]$ checksignal ${ちでじ}
device = /dev/pt1video2
C/N = 30.149291dB
...(snip)...

[user@host ~]$ checksignal ${CSちゃんねる}
device = /dev/pt1video0
C/N = 16.663467dB 
...(snip)...

誤差なのか、時間帯によるものなのか ... あんま変わんねぇ ...

でも、そもそもの閾値や平均値がわからないし、下がってないし、ケーブル自体が新しくなったのでメンテ終了。

しばらく運用して、ログを見てみよう。

goose の続き

goose mysql

https://bitbucket.org/liamstask/goose

鋭意移行中。

 

ところが、trigger を管理しようとしたら syntax error...

どうやら DELIMITER にうまく対応できてないっぽい。

 

1行なら普通に通る。

ソースは今度読む。

mysql のスキーマをバージョン管理したい

go goose mysql perl

移転先モンロー効果 - g.o.a.t


そろそろ積み上げ式の管理も限界。そのうち絶対事故る。


RoR とかだと楽なんでしょうけど、、、

で調べたところ
liamstask / goose — Bitbucket
ってのがひっかかりました。


go も初めてなので、ついでにちょっとやってみようと思います。

go と goose のインストール

sqlを修正

実行

確認


なるほど...

mysql> select * from goose_db_version;
+----+----------------+------------+---------------------+
| id | version_id     | is_applied | tstamp              |
+----+----------------+------------+---------------------+
|  1 |              0 |          1 | 2015-02-10 17:30:43 |
|  2 | 20150210171844 |          1 | 2015-02-10 17:31:52 |
+----+----------------+------------+---------------------+
2 rows in set (0.00 sec)
ロールバック
$ goose down
goose: migrating db environment 'development', current version: 20150210171844, target: 0
OK    20150210171844_create_first.sql

mysql> select * from goose_db_version;
+----+----------------+------------+---------------------+
| id | version_id     | is_applied | tstamp              |
+----+----------------+------------+---------------------+
|  1 |              0 |          1 | 2015-02-10 17:30:43 |
|  2 | 20150210171844 |          1 | 2015-02-10 17:31:52 |
|  3 | 20150210171844 |          0 | 2015-02-10 17:39:09 |
+----+----------------+------------+---------------------+

mysql> show tables;
+------------------+
| Tables_in_mig_db |
+------------------+
| goose_db_version |
+------------------+
1 row in set (0.00 sec)

なるほどなるほど...そういう事か...
インストールも楽だし、汚れないし、一から作るよりは断然楽ですね。
git と jenkins とゴニョって
Adam Spiers / MySQL-Diff - search.cpan.org
このあたりを使えば、デプロイの管理を楽に移行できそう。

その他

path とか env の指定。指定したpathの直下に dbconf.yml が必要みたい。src 見たけど、その辺りの細かい指定の仕方は無かった。(気がする)

$ goose -path="other_db_info_dir" -env="test" up
...(snip)...

Net::Amazon::S3 

Passing a list of values to enum is deprecated. Enum values should be wrapped in an arrayref. at /home///lib/perl5/x86_64-linux-thread-multi/Moose/Util/TypeConstraints.pm line 436.
        Moose::Util::TypeConstraints::enum('StorageClass', 'standard', 'reduced_redundancy') called at /home///lib/perl5/Net/Amazon/S3/Client/Object.pm line 21
        require Net/Amazon/S3/Client/Object.pm called at /home///lib/perl5/Net/Amazon/S3.pm line 17
        Net::Amazon::S3::BEGIN() called at /home///lib/perl5/Net/Amazon/S3/Client/Object.pm line 0
        eval {...} called at /home///lib/perl5/Net/Amazon/S3/Client/Object.pm line 0
        require Net/Amazon/S3.pm called at ./run.pl line 7
        main::BEGIN() called at /home///lib/perl5/Net/Amazon/S3/Client/Object.pm line 0
        eval {...} called at /home///lib/perl5/Net/Amazon/S3/Client/Object.pm line 0

pre-signed url ほしいだけなのに、依存モジュール多いし、めっさ警告でるので自前で実装することにした。

時間があるときに追いかけよう。