bundle updateが、http errorで使えないのに対処した
vpsを借りて、ubuntu24.04LTSを使っています。
bundle updateをしようとしたら、次のようなエラーで進めませんでした。
Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/ due to underlying error <Gem::Net::OpenTimeout: Failed to open TCP connection to rubygems.org:443 (execution expired) (https://rubygems.org/specs.4.8.gz)> Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/ due to underlying error <Gem::Net::OpenTimeout: Failed to open TCP connection to rubygems.org:443 (execution expired) (https://rubygems.org/specs.4.8.gz)>
少し調べたところ、IPV6を使えないことが原因らしいと分かりました。
Could not fetch specs from https://rubygems.org/と言われてbundle installできない時
それで、IPv4の優先度を高くする（=IPv6の優先度を下げる）ようにすれば良いのかなと考えて探した答えがこちら。
IPv4 を IPv6 より優先にする設定方法 - なっくの徒然日記
Linuxの設定の2番目をやってみました。
/etc/gai.conf
... #precedence ::ffff:0:0/96 10 ...
上記の行を見つけて、以下のようにコメントを外し、優先度を100に変更して保存すれば完了です。
/etc/gai.conf
... precedence ::ffff:0:0/96 100 ...
再起動の必要もありません。
無事にbundle update出来ました。
rubyのrqrcodeで背景色を白にしたQRコードを作る
rqrcodeを使ってQRコードを作ろうとしたところ、fill（背景色）にwhiteを指定しているので白になって欲しいのですが、透明になってしまって困っていました。
png = qr.as_png( resize_gte_to: false, resize_exactly_to: false, fill: 'white', color_mode: ChunkyPNG::COLOR_GRAYSCALE, color: 'black', size: 200, border_modules: 4, module_px_size: 10, file: nil #path to write )
githubでchunky_pngのソースコードを眺めていたら、rgbaで指定することが出来るようなので、aに255か1を入れれば白になるだろうと思ったのですが…透明のまま。まさかと思って0を入れてみたもののやはり透明のまま。
もしやと思って254を入れてみたら、無事に白になりました。
以下、rgbaでの指定方法。
png = qr.as_png( resize_gte_to: false, resize_exactly_to: false, fill: ChunkyPNG::Color.rgba(255,255,255,254), color_mode: ChunkyPNG::COLOR_GRAYSCALE, color: 'black', size: 200, border_modules: 4, module_px_size: 10, file: nil #path to write )
mysqlのbinlogでディスク容量を使い切った話
最近 https://kaori-info.com というサイトを作りました。
mysqlはまだわかってないことが多くて、ディスクを使い切ってしまいました。
理由と解決方法を調べたので備忘録として書いておきます。
何が起きていたか
ある日、サイトを見ると、500 internal errorが出ていたので何だろうと思ってサーバーに繋いで見に行きました。
インターナルエラーは、経験的にはアプリケーションサーバーが落ちてるか、データベースにつなげられない時が多かったので順番に見ていきました。 アプリケーションサーバーは生きていたので、mysqlにログインしてみたところ、こちらもログインは出来ました。しかし操作ができないことに気がつきました。それでdfコマンドを使ってみたらディスクを使い切ってることがわかりました。
解決方法
容量を喰っているところを探す
どこで大量に使われているかを探すために次のコマンドを実行しました。
# cd / # du -d1 -h |sort -h
として段階的にディレクトリを潜っていきました。
たどり着いたところが/var/lib/mysqlでした。
そこにたくさんあるbinlog.* 。
これでディスクを使い切っていました。
このログは、更新したときのログで、更新に失敗したりしたときに使うログらしいということがわかりました。
わたしは今のところそのログが無くても問題ないので、binlogの削除方法を探していてこの記事にたどり着きました。
このbinlogはファイルを削除するだけではダメなようなので、mysqlコンソールからbinlogを削除していきます。
ストレージの追加
困ったのは、mysqlにつなげられるものの、ディスクがいっぱいなので削除操作さえできないことでした。
conohaにサーバーを借りてるのでストレージを追加して、binlogの新しい方をいくらか待避してからpurgeしてある程度ディスクが空いたら、待避したbinlogを元の場所に戻してmysqlからpurgeすることにしました。
ストレージ追加方法
ストレージを借りて、VPC(VM)に接続（アタッチ）します。このときVPCが動いているとつなげられないので、一度シャットダウンします。
アタッチできたら、VPCを起動してログインし、lsblkで接続されているデバイス名を調べます。
fileコマンドを使って、初期化しようとしているデバイスが空っぽか確認します。
そのデバイスをmkfsして初期化します。
具体的なコマンドは下記を参考にしてください。
Linuxインスタンスを選ぶと出てきます。デバイス名は使ってる会社やシステムによって違うので、よく確認してください。
アタッチしたストレージの初期化～追加方法 Amazon EBS ボリュームを使用できるようにする
binlogの一部待避
そのドライブをmountでマウントして必要ならディレクトリを作って、さきほどのbinlogを一部移動させます。
例えば、新しいストレージを/mntにマウントしているとして、
# mv /var/lib/mysql/binlog.xxx6* /mnt
などとしてファイルを待避します。
削除する
ls binlog.* |head -20
とコマンドを打って、削除対象の具体的なファイル名を見つけます。
次に、
# mysql -u root
として、mysqlのコンソールを出して、
# purge master logs to 'binlog.xxxxxx';
とコマンドを書いて実行します。（binlogは別の名前のこともあるようです）
'binlog.xxxxxx'のxxxxxxの部分は数字なのですが、このpurgeコマンドは、その数字の1つ前までを一気に消してくれるので、最初少しずつ削っていって、負荷にもよりますが、わたしは半分くらい削ったところで一気に消しました。
以後のための対処方法
そして、/etc/mysql/mysql.conf.d を編集し
[mysqld] expire_logs_days=7
を追加しておきました。
そしてmysqldの再起動を忘れないように…
