2020年9月 – ページ 2 – 端くれプログラマの備忘録

[C#] .NET Core/Framework 違い

2020年9月16日2021年7月25日 @84kure

新しくアプリを開発する際に.NETのどのエディションを使うべきか。それを判断するためには .NET Core/Framework の違いをきちんと理解しておきたい。

というわけで、そのあたりを解説している参考サイトを覚え書きリンク。

.NET Standard – .NET Core と .NET Standard の分かりやすい解説 | Microsoft Docs
https://docs.microsoft.com/ja-jp/archive/msdn-magazine/2017/september/net-standard-demystifying-net-core-and-net-standard

サーバーアプリ用 .NET Core と .NET Framework の選択 | Microsoft Docs
https://docs.microsoft.com/ja-jp/dotnet/standard/choosing-core-framework-server

.NET Framework / .NET Standard / .NET Core とは何か？ | HIROs.NET Blog
https://blog.hiros-dot.net/?p=9086

.NET XXXの違いについて、ざっくりまとめてみた。 – Qiita
https://qiita.com/TowaOnohara/items/e202a2fcfa87d8a42ded

[OpenCV] OpenCvSharpでIplImageをBitmapへ変換する

2020年9月15日2021年7月25日 @84kure

ファイルを介して変換するのも一方法。

IplImage mat;
mat.SaveImage("test.png");
Image image = Image.FromFile(tbImageFile.Text);

IplImage mat;

mat.SaveImage("test.png");

Image image = Image.FromFile(tbImageFile.Text);

だけど、いちいちファイルを作るのは無駄だ。調べたら、BitmapConverterという変換処理を集めたクラスがあったのでそれを使う。

using OpenCvSharp.Extensions;
IplImage mat;
Image image = BitmapConverter.ToBitmap(mat);

using OpenCvSharp.Extensions;

IplImage mat;

Image image = BitmapConverter.ToBitmap(mat);

参考サイト

BitmapConverter Class
https://shimat.github.io/opencvsharp_docs/html/cba415e7-fa73-8ff3-772b-3c9e583143b1.htm

OpenCvSharpでのIplImageとBitmapの相互変換 – そこに部品があるから
http://nc30mtd.oops.jp/blog/2015/01/opencvsharpiplimagebitmap.html

[Laravel] Routeキャッシュをクリアする

2020年9月14日2021年7月25日 @84kure

新しいrouteを定義したのに、アクセスしたら404になるときには、routeのキャッシュを疑おう。

$ php artisan route:list
新しいrouteがリストされない。

$ php artisan route:clear
キャッシュクリア

$ php artisan route:list
新しいrouteがリストされた。

$ php artisan route:list

新しいrouteがリストされない。

$ php artisan route:clear

キャッシュクリア

$ php artisan route:list

新しいrouteがリストされた。

[MySQL] バイナリデータのダンプ方法

2020年9月13日2021年7月25日 @84kure

blobなどバイナリデータを持つテーブルをダンプすると、バイナリデータは文字化けしてしまう。当たり前だけど。

対策としては、バイナリデータを持つテーブルをダンプするときは –hex-blob を指定する。バイナリデータが16進文字列に変換されてダンプされる。こうして作成したダンプをインポートするときは普通通りで良し。

$ mysqldump -u user -p --hex-blog sample > sample.sql

1	$ mysqldump -u user -p --hex-blog sample > sample.sql

参考サイト

mysqldump で default-character-set とか hex-blob とか – ngyukiの日記
https://ngyuki.hatenablog.com/entry/2018/06/21/220624

[MySQL] ログの日時のタイムゾーンを設定する

2020年9月12日2020年9月9日 @84kure

MySQLを5.6から5.7にアップグレードしたら、ログに記録される日時のタイムゾーンが日本時間からUTCに変わった。おそらく規定値が変わったのだろう。MySQLのドキュメントを調べたら、ログのタイムゾーンを設定するシステム変数が見つかった。システムのタイムゾーンを使うように設定しておく。

/etc/my.cnf

[mysqld]
log_timestamps=SYSTEM

1 2	[mysqld] log_timestamps=SYSTEM

参考サイト

MySQL :: MySQL 5.7 Reference Manual :: 5.1.7 Server System Variables
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html

MySQLのバージョンをあげたら、ログ出力される時間がおかしくなった – Qiita
https://qiita.com/tachitechi/items/768b6f63112a8ddf34c9

[MySQL] ログに「Access denied for user ‘UNKNOWN_MYSQL_USER’@’localhost’」と記録される理由

2020年9月11日2020年9月9日 @84kure

MySQLを5.6から5.7にアップグレードしたら、MySQLを起動する度にログに以下が記録される。

/var/log/mysqld.log

2020-07-21T17:17:56.704754Z 2 [Note] Access denied for user ‘UNKNOWN_MYSQL_USER’@’localhost’ (using password: NO)

ネットを検索すると以下の記事がヒット。

Access denied for user ‘UNKNOWN_MYSQL_USER’@’localhost’ (using password: NO)
https://blog.trippyboy.com/2011/mysql/access-denied-for-user-unknown_mysql_userlocalhost-using-password-no/

記事には「MySQLが起動する時に自身が起動済みかどうかを確認するためにMySQLサーバーに接続を試すため」とある。起動スクリプトを眺めてみると、確かにそのような目的でログインを試みているようだ。

しかし、調べてみるとMySQL5.6でも同様の処理を実行している。どうしてMySQL5.6だとログに出てこないのか？5.7になってログレベルの規定値が変わってログに現れるようになっただけ？まあ大勢に影響無さそうなので、調査は打ち切る。

参考サイト

MySQL 5.7.17 startup log showing [Note] Access denied for user ‘UNKNOWN_MYSQL_USER’ – Stack Overflow
https://stackoverflow.com/questions/42329432/mysql-5-7-17-startup-log-showing-note-access-denied-for-user-unknown-mysql-us

日々の覚書: 何も考えずに真っ新なCentOS 6.6にMySQL 5.7をyumで叩き込むメモ
https://yoku0825.blogspot.com/2015/06/centos-66mysql-57yum.html

[MySQL] zombie dump threads対処法

2020年9月10日2020年9月13日 @84kure

MySQLを5.6から5.7にアップデートしたら、MySQLログに以下のメッセージが記録されるようになった。レプリケーションしているマスター側のログのみに記録されている。

/var/log/mysqld.log

2020-07-24T03:39:03.790695+09:00 363 [Note] Start binlog_dump to master_thread_id(363) slave_server(369034799), pos(mysql-bin.000018, 70234)
2020-07-24T03:40:03.896291+09:00 366 [Note] While initializing dump thread for slave with UUID <be434b09-3c76-11ea-b276-0e1a567dc58c>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(363).
2020-07-24T03:40:03.896398+09:00 366 [Note] Start binlog_dump to master_thread_id(366) slave_server(369034799), pos(mysql-bin.000018, 70234)
2020-07-24T03:41:04.019671+09:00 369 [Note] While initializing dump thread for slave with UUID <be434b09-3c76-11ea-b276-0e1a567dc58c>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(366).

ネットを検索すると同じ現象がヒットした。

replication – MySQL Zombie Dump threads – Stack Overflow
https://stackoverflow.com/questions/38500713/mysql-zombie-dump-threads

MySQL :: MySQL Zombie Dump threads.
https://forums.mysql.com/read.php?26,648406,648406#msg-648406

記事によれば、slave_net_timeオプション(スレーブがマスターからのデータを待機する時間)の規定値が、MySQL 5.6では3600秒だったのが、MySQL 5.7では60秒に変更されているらしい。

おそらくウチの構成だと60秒では短すぎるのだろう。スレーブ側でMySQL 5.6の規定値だった3600に設定しなおしたら解決。とりあえずこれでしばらく様子を見る。

# mysql -u root -p
mysql> set global slave_net_timeout=3600;

1 2	# mysql -u root -p mysql> set global slave_net_timeout=3600;

参考サイト

第75回　MySQLのさまざまなタイムアウトオプションについて：MySQL道普請便り｜gihyo.jp … 技術評論社
https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0075

[MySQL] ユーザパスワードを変更する

2020年9月9日2020年9月7日 @84kure

前任者がWebアプリ用にMySQLユーザを作成らしいけど、Webアプリの設定を見るとrootでMySQLに接続している。せっかく作成したユーザが使われていないのは無駄だし、権限何でもアリのrootでMySQLに接続しているのは危険なので、そのユーザを使いたいのだけどパスワードがわからない。

調べてみると、ユーザのパスワード設定は簡単にできた。

$ mysql -u root -p
mysql> SET PASSWORD FOR user1@localhost=password('pass123');
mysql> exit;

$ mysql -u root -p

mysql> SET PASSWORD FOR user1@localhost=password('pass123');

mysql> exit;

ログインできるか確認する。

$ mysql -u user1 -p
Enter password: pass123

1 2	$ mysql -u user1 -p Enter password: pass123

ログインできた。

以上覚え書き。

[MySQL] タイムゾーンを設定する

2020年9月8日2020年9月6日 @84kure

稼働中のLaravelサイトをローカルに複製するために、DBをダンプしてローカルにインポートしたところ、ローカルのLaravelが以下のエラーを吐いた。

$ php artisan config:clear
In Connection.php line 664:
SQLSTATE[HY000]: General error: 1298 Unknown or incorrect time zone: 'Asia/Tokyo' (SQL: select `value`, `key` from `
setting`)
In PDOStatement.php line 123:
SQLSTATE[HY000]: General error: 1298 Unknown or incorrect time zone: 'Asia/Tokyo'
In PDOStatement.php line 121:
SQLSTATE[HY000]: General error: 1298 Unknown or incorrect time zone: 'Asia/Tokyo'

$ php artisan config:clear

In Connection.php line 664:

SQLSTATE[HY000]: General error: 1298 Unknown or incorrect time zone: 'Asia/Tokyo' (SQL: select `value`, `key` from `

setting`)

In PDOStatement.php line 123:

SQLSTATE[HY000]: General error: 1298 Unknown or incorrect time zone: 'Asia/Tokyo'

In PDOStatement.php line 121:

SQLSTATE[HY000]: General error: 1298 Unknown or incorrect time zone: 'Asia/Tokyo'

ローカル(CentOS7)のMySQLには’Asia/Tokyo’というタイムゾーンが定義されていないみたい。

参考サイトの手順に倣ってタイムゾーンデータをインポートすることで解決。

$ sudo /usr/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo > ~/timezone.sql
$ mysql -u root -p -Dmysql < ~/timezone.sql
Enter password: *****
$ sudo vi /etc/my.cnf
[mysqld]
default-time-zone = 'Asia/Tokyo'
$ sudo service mysqld restart

$ sudo /usr/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo > ~/timezone.sql

$ mysql -u root -p -Dmysql < ~/timezone.sql

Enter password: *****

$ sudo vi /etc/my.cnf

[mysqld]

default-time-zone = 'Asia/Tokyo'

$ sudo service mysqld restart

参考サイト

MySQLでタイムゾーンを設定する – Qiita
https://qiita.com/tailak/items/63dce2dd7dfe049b038e

[MySQL] mysqlcheckでテーブルをエラーチェックする

2020年9月7日2020年9月9日 @84kure

もしかしてテーブルが破損してるかも？と思ったので、mysqlcheckでエラーチェックする。

ちなみに、mysqlcheckには以下の4つの機能があるらしい。

テーブルのエラーチェック (デフォルト)
テーブルの分析 (–analyze オプション)
テーブルの最適化 (–optimize オプション)
テーブルの修復 (–repair オプション)

全データベースをチェックする場合

# mysqlcheck -c -u root -p --all-databases

1	# mysqlcheck -c -u root -p --all-databases

sampleデータベースのみをチェックする場合

# mysqlcheck -c sample -u root -p

1	# mysqlcheck -c sample -u root -p

参考サイト

MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.5.3 mysqlcheck — テーブル保守プログラム
https://dev.mysql.com/doc/refman/5.6/ja/mysqlcheck.html

テーブルが壊れているかと思ったので、mysqlcheckで修復したときのメモ – Qiita
https://qiita.com/tachitechi/items/e8fd8f8fbf34a3bd884d