おふとんの中から寝言をつぶやく

ビットコインなどの暗号(仮想)通貨関連の話題を中心に雑多に書きます。

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の削除方法を探していてこの記事にたどり着きました。

MySQLのバイナリログ削除タイミング

この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の再起動を忘れないように…

dpkg: error processing package grub-efi-amd64-signed

トラブルシューティングの備忘録

Ubuntu24.04.01で、apt upgradeをしていて以下のようにgrub-efi-amd64-signedでエラーが出たときは、

Setting up grub-efi-amd64-signed (1.202.2+2.12-1ubuntu7.1) ...
mount: /var/lib/grub/esp: special device /dev/disk/by-id/scsi-0ATA_QEMU_HARDDISK_QM00001-part1 does not exist.
       dmesg(1) may have more information after failed mount system call.
dpkg: error processing package grub-efi-amd64-signed (--configure):
 installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32

/var/cache/debconf/config.datのバックアップを取る

適当なエディタを使って/var/cache/debconf/config.datを開いて、grubを探す

# cp /var/cache/debconf/config.dat  /var/cache/debconf/config.dat.bak
# vi /var/cache/debconf/config.dat

(SCSIバイスは使っていないので) Value=/dev/disk/by-id/scsi-* となっている項目を削除する

その後、

# apt upgrade

する

参考:【Ubuntu 22.04】grub-efi-amd64-signed設定エラーの解決: /var/lib/grub/espマウント問題