「MariaDB」の記事 - Crieit

匿名掲示板作ってみた

2021-11-22T02:31:55+09:00

匿名掲示板を作り、アルファ版として公開してみました。
Crieitユーザーの皆さんにもぜひご意見いただきたいです。

　　　　　　　　　　 -‐ '´￣￣｀ヽ､へ　　　　／＼
　　　　　　　／　／" ｀ヽヽ　　￣￣￣￣　　 >
　　　　　　　　　//, '/　　　　ヽﾊ　､　ヽ￣￣＞／
　　　　　　　　〃 {{⌒　　　 ⌒ﾘ| ｌ │ i| ／　／
　　　　　　　　ﾚ!小ｌ●　　　 ● 从　|、i| /　
　　　　　　　　ヽ|l⊃　､,､,　⊂⊃　|ﾉ│|＿＿＿＿_／
　　　　 /⌒ヽ|ﾍ　　ゝ._）　　j /⌒i !
　　　　　　＼ /:::::|　l＞,､ __,　イァ/　 /│
.　　　　　　 /:::::/|　|　ヾ:::|三/::{ﾍ､∧ |
　　　　　　　｀ヽ< |　|　　ヾ∨:::/ヾ:::彡'　|

その名も、「よろずネットワーク」です。
作った目的は、「世の中のトレンドがわかって」「自由でゆるくて」「ネットの面白かった時代を再現できるような」掲示板を作りたいと思ったことです。

よろずネットワーク

ちなみに、よろずネットワークではAAを綺麗に投稿できます。

コメント欄はこんな感じです。

スレにはyoutube動画やニコニコ動画も貼り付けできます。

技術スタック
サーバー：Conoha VPS(ubuntu 20.04LTS) ×複数
DB: Mariadb on Conoha
バックエンドAPI：Django Rest Framework
フロントエンド: Quasar（Nuxtjsみたいなやつ）でSSR(PWAﾓｰﾄﾞ)
ドメイン：google domain
CI/CD:github actions

毎日アバター画像が自動生成されたり、返信がくると通知が来たり、カテゴリごとに毎時ランキングを見られたりなど、掲示板として使いやすいものを意識して作ったので、是非遊びに来てみてください！

　よろずネットワーク

MariaDB (MySQL innoDB) が急にダウンする際に行ったパラメーターチューニング

2020-04-06T06:18:12+09:00

はじめに

処理が遅いアプリの改善を行った後、処理性能が改善されたものの、MariaDB が急に落ちる問題が頻発。
落ちるたびにシステムが停止し悩まされたが、なんとか解決したので備忘録。

結論

アプリ側で処理数が上昇した事で、IO 負荷が高くなっていた事が根本原因。
ストレージの IOPS を考慮して innodb_io_capacity, innodb_io_capacity_max, innodb_read_io_threads, innodb_write_io_threads を可能な限り増やす。増やすと上昇値が平準化される。負荷が上がり innodb_log_file_size の上限を超えて落ちることが無くなる。
innodb_buffer_pool_size は可能な限り上げる。余裕を持たせ処理を平準化させる。
innodb_log_buffer_size も一定水準まで上げる。上の対処を行った場合でも、負荷が上昇するとこの数値次第で落ちる原因になる。

環境

項目	値
筐体・メモリ	さくらVPS 16GB
ストレージ	SSD
用途	nginx PHP ウェブサーバー + DB サーバー

具体的な my.ini 設定値 (関連値含む)

innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_read_io_threads = 12
innodb_write_io_threads = 12
innodb_buffer_pool_size = 6144M
innodb_log_buffer_size = 250M

innodb_buffer_pool_instances = 4
innodb_flush_method = O_DIRECT
innodb_checksum_algorithm = CRC32
innodb_change_buffer_max_size = 10
innodb_log_file_size = 256M
innodb_log_files_in_group = 2
innodb_lock_wait_timeout = 10
innodb_lru_scan_depth = 1024
innodb_flush_neighbors = 0
innodb_read_ahead_threshold = 0

経緯や補足など

特定の処理タイミングでのみ落ちていた為、アプリ側の問題を疑ったが、単純な参照と更新を繰り返すだけの処理な為、アプリ側の問題はほぼなかった。
MariaDB そのものについての情報が少ない。MySQL の情報はそこそこある為、適宜参考にする。
用いている MariaDB 10 は MySQL 5.6, 5.7 両バージョンをベースとしたキメラで若干ややこしい。
監視ツールの Mackerel の MySQL プラグインが役立った。知識がなくとも何かが制限を超えたような事が見て取れるので当たりが付けられた。
innoDB Checkpoint Age (Uncheckpointed) が急激に上昇し MariaDB が落ちていた。当初は innodb_log_file_size を上げて解決を図った。
多少ライフタイムが伸びたが、問題の根本は IO パフォーマンスにある為、上記は本質的な解決策にならず同様の問題が発生していた。
IO パフォーマンスはあくまで設定次第であり、物理側の IOPS に併せて勝手にスケーリングされる訳ではない。
ストレージが HDD では対処不能だったので SSD で助かった。
上記パラメーターが最善値であるか不明。安定し始めてから1週間程度な為、再調整の可能性あり。

参考

MinQ開発日記 (6) ローカルのGoの開発環境の構築とスキーマ・マイグレーション

2019-12-20T16:47:14+09:00

Echoによるエコー・サーバー

とりあえずEchoサーバーを立てる. またローカルに開発環境を構築していなかったことを思い出す. やり方はMinQ開発日記 (3) Docker上にGo開発環境を構築と同じと思ったのですがGo Modulesというのがあるようです.

構成

Echo (Webサーバー兼アプリケーション)
MariaDB Docker Container
React (認証画面とCRUDインターフェース)

goenvとGo Modules

Goのバージョン1.13以降は何もしなくてもGo Modulesが使えるようです.

その前にGoのバージョン管理ができるようにしましょう. pyenvやnodeenvのようにgoenvというのがあります. 公式のInstallationガイドを読むと大体わかります. GOENV_ROOTがgoenvバイナリのロケーションです.

export GOENV_ROOT="$HOME/.goenv"
export PATH="$GOENV_ROOT/bin:$PATH"
eval "$(goenv init -)"
export GOPATH="$HOME/go"
export PATH="$PATH:$GOPATH/bin"

goenvでインストール可能なバージョンを列挙するには以下のようにします.

goenv install -

バージョンがずらっと並ぶので, この中から一つ選んでインストールします. 最新版(2019/12/14時点)である1.13.4をインストールします.

goenv install 1.13.4
goenv global 1.13.4

これでgoのバージョンは1.13.4です. Go Modulesは好きなところにフォルダを作れます.

cd ~/your_folder
mkdir minq && cd minq
go mod init

これでgo.modというファイルができました. 適当にserver.goというファイルを作ります(多分main.goの方が良い気もする).

package main

import (
    "net/http"

    "github.com/labstack/echo"
)

func main() {
    e := echo.New()
    e.GET("/", func(c echo.Context) error {
        return c.String(http.StatusOK, "Hello, World!")
    })
    e.Logger.Fatal(e.Start(":1323"))
}

minqフォルダ内部で以下を実行すると必要なパッケージ(例えばecho)なんかを勝手にダウンロードしてきて, ビルドしてくれます.

go build

minqフォルダの生成物はフォルダ名と同じになるのでこの場合はminqです.

./minq

サーバーが起動したらオッケーです. 特別依存性を指定しなくてもimportから解決してくれるっぽいのは良いですが, 反面githubのレポジトリを直接指定する必要があるのは少し面倒でもあります.

MariaDB

brewで入れます.

brew install mariadb

起動もbrewを使います.

brew services start mariadb

起動したデータベースへアクセスします.

sudo mariadb -uroot

GORMで必要になる情報

GORMからMariaDBにアクセスするには以下の情報が必要になります.

username
password
IPアドレス/ホスト名
ポート番号
データベース名

username & password

上の例でmysqlというデータベースがあると思います. このデータベースにuserというテーブルがあります.

SELECT user FROM mysql.user;

名前が被らないように, ここに新しいユーザーを登録します. CREATE USERを使います.

CREATE USER 'new_name'@'localhost' IDENTIFIED BY 'your_password';

new_nameというユーザーにyour_passwordでアクセスできます. ホストはlocalhostです.

ポート番号

システム変数を指定すると以下のように表示できるようです.

show variables like 'port';

SHOW VARIABLES
port

ちなみに私の環境では3306でした(多分誰でも同じ).

データベース名

MariaDBがアクセスしたユーザー用に管理してるデータベースを表示するのは簡単です.

SHOW DATABASES;

testというテスト用のデータベースが存在するはずです. とりあえずこれを使います.

USE test;

これでデータベースがtestに切り替わります. 後でGOMRでちゃんとスキーマが設定できたかを確認しましょう.

GORM

GORMでtestデータベースにアクセスしてみましょう. ハンドラを作っておきます. ステータス・コードなんかは現状適当です(DBサーバーでエラーが出たらどうしたら良いのかわからないので).

func accessDB(context echo.Context) error {
    db, err := gorm.Open("mysql", "root:@(127.0.0.1:3306)/test?charset=utf8&parseTime=true")
    defer db.Close()

    if err != nil {
        return context.String(http.StatusOK, err.Error())
    }

    return context.String(http.StatusOK, "Connect to DB")
}

この時点では以下のようなエラーが出力されます. これはrootユーザーでアクセスする場合sudoer出ないと実行できないからのようです.

Error 1698: Access denied for user 'root'@'localhost'

Connect to mysql server without sudo

ここで上で作ったnew_nameユーザーを使いましょう(名前は適宜読み替えてください). testというデータベースがデフォルトで存在するはずなのでそれを指定しましょう.

db, err := gorm.Open("mysql", "new_name:@(localhost:3306)/test?charset=utf8&parseTime=true")

該当箇所を変更してビルド&リスタートするとConnect to DBと表示されるはずです(末尾のクエリ文字列的なのは一旦無視します).

e.GET("/v1/example/mariadb", accessDB)

スキーマ・マイグレーション

データベースのスキーマの更新を行う作業をスキーマ・マイグレーション, あるいは単にマイグレーションと言うようです. ORM(Object Relational Mapping/Mapper)ではオブジェクト(Goの構造体)のフィールドからスキーマを決めるようです. つまり個々のテーブル上のレコードと構造体のインスタンスが対応関係にあるわけです.

type User struct {
    ID   int
    Name string
}

テーブル名は自動的に雛形となる構造体名の複数形になります. この場合だとusersというテーブルがtestデータベースに追加されます.


if db.HasTable("users") {
    return context.JSON(http.StatusCreated, "User table is already existed")
}

db.AutoMigrate(&User{})

return context.JSON(http.StatusCreated, "Create users table")

適当なハンドラ関数を作って, エンドポイントに紐付けます. MariaDBに戻って以下を実行します.

SHOW COLUMNS FROM users;

これでusersの構造が表示されるはずです.

まとめ

EchoからGORMを通じてMariaDBにアクセスすることができました. GORMのチュートリアルでは利用するデータベースの操作には慣れている前提なのか少しつまづきました.

今後

React

データベースを管理するCRUD用のインターフェースを作ります. formikやDraft.jsを使います. これはできたらPWA(Chrome Desktop)にしてネイティブ・アプリのように実行できるようにしたいです. 詳細に踏み込みたくないのでcreate-react-appを使います. またテストにはCypress.jsを使ってみたいです.

認証

現状他の人は使わない前提なので, 実験的にWebAuthenticationを使おうと思っています.

Gitの導入

プロジェクトはバージョン管理をするのですが, このままだとgom.Openに指定したデータベースのパスワードが丸見えです. 色々方法があるようです. 最初はコマンドライン引数で渡せばいいのかと思ったのですが, Stackoverflowで質問してみるとダメだそうです. コマンドラインにセンシティブなデータを渡すことがそもそもタブーのようです.

What is a standard way to specify password for MariaDB in an API server?

じゃあどうするのか?

まずそもそも構成ファイルをgitの管理下に置かないという手があります(.gitignore). あるいは構成ファイルに.exampleのような拡張子を付け適当なパスワードを入れて本番用とは切り分けるやり方です.

What is the best practice for dealing with passwords in git repositories?

ただこの方法はどちらかというとプロジェクト・テンプレートを公開するような用途に使った方がいい気もします. どちらの方法も認証情報は別の方法で管理する必要があります.

もう一つはVaultというソフトウェアを使う方法ですが, こちらはかなり大げさなようです.

4 secrets management tools for Git encryption

今回はgit-cryptやgit-secretというのがあるようでこの辺を調べてみようと思います.

STORING ENCRYPTED CREDENTIALS IN GIT
本番用の.envを外部に一切知られずに安全にgithubで保存する方法
 Gitリポジトリ暗号化のススメ - git-secret -
Git

Reference

【Go】goenvを使ってGo1.13.4の環境構築
 Go Modulesも触れてみるGo入門
 Go言語のGORMを使ってみた①
Golang + GORM + MySQL でデータをやりとりする

MinQ開発日記 (5) MinQが目指すもの & テーブル設計

2019-12-12T21:21:54+09:00

MinQとは何なのかを考える

動機

勉強がてら適当に作っていたAPIサーバー. このデータベースのテーブル設計を考え始めたらどんなデータを収めるべきなのかを考える必要が出てきた. めんどくさいわけだが, これはMinQを具体的に掘り下げるのにいい機会にもなると思った.

MinQを作ろうと思った理由

基本的には勉強履歴を付けようと思ったからです. ただそのためのルールとかサービスで自分に合うものがなかった(見つけられなかった)のでポートフォリオがわりになるかと思って作り始めました.

より良い勉強法とは?

勉強に王道はないとよく言われる. 特に楽な方法はないとされます(睡眠学習にも一定の効果があると言う話もあるという話もありますが・・・). 反復学習が必要でモノの本には脳に汗をかかせることが大事と言う趣旨のことが書いてあった記憶があります. とはいえ闇雲にやっても暗中模索で, 迷子になるのがオチだし, 忘却曲線のように効果がある勉強法もいくつか存在するのは確かです. アウトプットが良いなんて話もあって, 勉強したことをブログに書くと言うこともあるだろう. 備忘録にもなるので設定や環境構築なんかではやる人も多いわけですが, 実際はググった方が速かったりします.

勉強法

いち初学者として自分が勉強する上でどうやれば良いのかを考えた. また教育系の一般書に目を通して比較的効率的な学習法も調べた. その結果現状あまり良い勉強法と言うか環境が提供されていない気がした.

勉強法	利点	弱点
アウトプット	情報を共有できる	グーグル検索問題
動画	分かりやすい	効率がいまいち
文章チュートリアル	分かりやすい. 動画よりは効率的	探すのが辛い
スクール	ピア・プレッシャでモチベーションを維持できる	高額, 初心者向けしかない
検定(情報処理技術者試験, LPIC)	基準が明確	試験のインターバルが長い
本	情報の精度は高い(はず)	古い, カリキュラムが組みにくい

誰でも一つまたは複数の勉強法を試したことがあるはずです. さてこのようにコンテンツは沢山あり勉強するには良い時代・・・となりそうですが(別に否定はしませんが), 個人的な不満があったりします.

本

情報が古いとかは承知で買うしそれはそれで勉強になったりするのですが, 復習が困難です. 本によっては課題や復習問題が付いていますが, それを自分で管理するのは面倒です. 特に大量にインプットしたらもう一度同じ本を読むのは億劫です. また全体のカリキュラムも描き難いです. 内容ごとに言語にまたがることも多いので,　効率性も微妙な気はします.

検定

テストは学習において効果が高いとされていますが, 難易度の調整が微妙な気がします. もっと柔軟な習熟度に合わせた学習法が実現できそうです. 他にもテストのインターバルが長すぎる, 学習履歴が残らないと点が不満です.

動画

動画は見ていると楽しいものもありますが, プログラムの場合追いにくい場合があります. 結局GitHubなどに置かれている完成品を読んだり写経するという羽目になったりします. 復習もやりずらいです.

スクール

金がない(以上)

文書

ブログのことと思えばいいです. 検索してヒットするとありがたいのですが勉強法としては, 疑問です. 結局ドキュメントのメモだったりするものもあり, ドキュメントを読むということも多々あります. ただエラーへの対処とかは便利だと思います.

アウトプット

勉強記録とかGitHubにひたすらコードをあげるという感じです. この開発日記もその一つでしょう. 人に教えるというのは高い学習効果があるとされていますのである程度の効果は見込めそうです. しかし見返す前に同じ内容をググってしまったり, 単なるメモや記事として価値がないようなもの(この記事みたいな?)があったりします. さらに時間がかかります. とはいえ自分の記事に助けられるという機会があった人もいるでしょう.

MinQはどうする?

これらを踏まえてMinQはどうするかです. MinQはクイズベースです. 形式としてはLPICが一番近い気がしますが, 別にプログラミングに限る必要はなく英語や数学なんかもやってみたいです. また学習履歴も細かく管理したいですが, 学習管理サービスは別に作るつもりなのでここでは考えません.

なぜクイズ?

テスト形式が比較的学習効果が高いそうです(確かそうだったはずです). 作りやすいし, 還元的な手法は物事を理解する基本だと思います. 解析とかもしたいのでデータを細かく取りたいというのもあります. 学習者(現状対象者は私だけですが)は理解していることよりもしていないことを知りたいわけです. また隙間時間で学習できるようにしたいというのもありこの形式を採用しました.

学習のリズムを作る
適切な問を適切な時に

従来のクイズ・アプリ/サービスとの違いは?

あくまで個人の実験用アプリなのであんまり詳しく考えてませんが, 以下のような感じでしょうか.

隙間時間の有効活用
復習のしやすさ
忘却曲線
知識/能力の可視化

究極の目標は知識/能力の可視化です. クイズだと単位が小さすぎるのでどうなるか分かりませんが, 知識や技術をネット上で短く切り売りできたら面白いかなと思っています. PRaasS (PRogrammer As a Service)とでも呼んでおきましょうか.

そういう意味ではクイズが目的というよりは能力を可視化するというのが大きな目標になりそうです.

テーブル設計

でようやく本題ですが, 関係データベースはテーブルから構成されるのですが, テーブルはスキーマと呼ばれる構造を持っています. まずはデータを編集するための管理画面(adminページ)用のテーブルが必要にあります.

カラム名	用途
id	主キー
user_name	ユーザーの名前
email	メール・アドレス
password	暗号化したパスワード

こんなところでしょうか. 次はクイズ・テーブルが必要です.

カラム名	用途
id	主キー
question	問題文
answer	回答/解説
tag	グループ/カテゴリ名

こんなカラムがあれば良いと思うのですが, 問題はanswerカラムとtagカラムです.

問答のフォーマット

いろんな形式がありますが, MinQではThe Jupyter Notebook Formatを参考しようと思います. この形式の利点は以下です.

複数の形式を簡単に扱える
ビューをシンプルに保てる

リスト構造なのでビュー側での表示のロジックが簡単になります. またセルごとに形式を指定するのでパースして内容を解析するという工程が不要です. 例えばMarkdownに数式やコードを埋め込むと, 該当箇所を判別して違うレンダラを利用する必要があります. これをセル単位で管理すると文章か数式かコード片か, あるいは画像かなどは即座に判断できます. 表示もセルのリストなので比較的簡単です.

tagと関連実体

クイズの分類のためにタグをつける場合, クイズが複数の分類に跨ることは普通にありえることです.そのためクイズには複数のタグを持たせられるようにするべきです. 一方でタグからクイズを絞り込むということもできた方が便利でしょう.

A Tour of Tagging Schemas: Many-to-many, Bitmaps and Moreにはいくつかの方法が解説されていて面白いです.

もっとも素朴な解決策はタグをCSV(Character Seperated Value)形式で保存する方法です. 表示だけのことを考えるとこれで十分ですが, タグをつける理由は表示のためではないでしょう. またビットマップという手法もあります. ビット列をそれぞれのタグの有無と対応づける方法です. n番目のビットが1ならAタグが付いていることと見なすわけです. この方法は検索は効率的ですが, ビット列以上のタグを持てません.

達人に学ぶDB設計徹底指南書では学生エンティティと講義エンティティの例が示されています. 両者を繋ぐのが関連実体/関連エンティティの受講です. この受講エンティティと呼ばれるエンティティは学生エンティティと講義エンティティの主キーを組み合わせたキーを主キーします. こうしたテーブル間の関係を多対多の関連 (Many-to-Many relationship)というらしいですが, GORMではJoinテーブルという中間テーブルで管理するようです. この機能を使うようにします.

## MariaDB

RDBMS(Relational DataBase Management System)としてはMariaDBを使おうと思います.

### 導入

CentOS 7にはMariaDBが入っていますが, 5.5とバージョンが古いです.

```bash
$ yum list installed | grep mariadb

mariadb.x86_64 1:5.5.64-1.el7 @base
mariadb-libs.x86_64 1:5.5.64-1.el7 @base
mariadb-server.x86_64 1:5.5.64-1.el7 @base
```

これをまずアンインストールします. How to install MariaDB 10 on CentOS 7 / RHEL 7に従って, インストールします. 現状ではバージョン10.4が安定バージョンのようです.

bash sudo systemctl enable mariadb sudo systemctl start mariadb

これでMariaDBが起動しました.

セキュリティ

次はセキュリティの設定です.

sudo mysql_secure_installation

基本的には全てYesでいいらしいです. 途中rootパスワードの設定が必要なのでパスワードを用意しておきましょう.

mysql -u root -p

上で設定したパスワードを入力してMariaDBと表示されればオッケーのようです.

文字コードの変更と寿司ビール問題

デフォルトの文字コードはutf8とlatin1が混在しているのですが, これをutf8mb4という絵文字も扱える方式に統一するという話です. またutf8mb4にしても照合順序の関係で寿司とビールの絵文字が同値として扱われるという問題があるそうです. ただいずれも絵文字に対応する処理なので現状関係なさそうなのでほっときます.

MariaDB(MySQL)初期設定時のセキュリティとutf8mb4化の手順を参照するなりググルなりしてください.

まとめ

次は管理画面とログイン機能を作っていきたいと思います.

Reference

Install MariaDB on CentOS 7
How To Install MariaDB on CentOS 7

KUSANAGI で MySQL が頻繁に落ちる際の対処

2019-04-14T15:12:18+09:00

環境

名前	バージョン
VPS	さくらインターネット 4GB
OS	KUSANAGI 8.4.2-2 (CentOS7 ベース)
ウェブサーバー	nginx 1.15.10
PHP	PHP 7.3.4
MySQL	MariaDB 10.1.38
アプリケーション	WordPress
その他	Mackerel

問題発生

サイトにブラウザからアクセスすると「データベース接続確立エラー」となる。

状況確認

コンソールにて。

sudo cat /var/log/messages

以下のログを発見。

Apr 14 00:31:06 hoge kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

MySQL が落ちている。

暫定対処

コンソールにて。

sudo systemctl start mysqld

「データベース接続確立エラー」は解消される。

数時間後に問題再発

「データベース接続確立エラー」

再度状況確認

コンソールにて。

sudo cat /var/log/messages

同様のログを確認。

Apr 14 07:48:32 hoge kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Mackerel でのメモリ状況を確認。

メモリを食いつぶした後スワップまで喰って無事死亡している。

nginx ログの確認

詳細は割愛するが、nginx のログを確認したところ、ブルートフォースアタックでの接続数増、pubsubhubbub での接続数増、行儀の悪い bot からの接続数増など様々な痕跡があった。

なお、KUSANAGI による nginx ログは以下の場所に分散している。
（筆者はしばらくの間ログ分散に気付かず、確認に時間がかかった。）

WordPress SSL

/home/kusanagi/kusanagi_html/log/nginx/ssl_access.log

※ kusanagi_html はプロビジョニングディレクトリ

WordPress HTTP

/home/kusanagi/kusanagi_html/log/nginx/access.log

※ kusanagi_html はプロビジョニングディレクトリ

WordPress 外

/var/log/nginx/access.log

恒久対処

コンソールにて。

sudo vim /etc/php-fpm.d/www.conf
/pm.max_children = 
i

PHP-FPM の設定を変更する。

pm.max_children = 50

を以下に変更。

pm.max_children = 17

[esc] キーで編集終了。

KUSANAGI (nginx + php-fpm) 再起動

sudo kusanagi restart

対処後の確認

Mackerel でのメモリ状況

ピーク時のメモリ消費量が 3.5GB 程度と、上限の 4GB から 0.5GB 程度余裕のある状態で消費しきらずに、スワップアウトも発生しない。

結果、「データベース接続確立エラー」とならず接続状況は安定している。

解説

PHP-FPM の pm.max_children はアプリケーションの最大プロセス数。php.ini ファイルでの memory_limitは 128M に設定されているため、pm.max_children を 17 に設定した場合 PHP-FPM のみで食いつぶすメモリ量を 2GB 程度に抑えることができる。
デフォルトで 1GB 程度消費しているため、計約3GB。さらに MySQL などで 0.5GB 程度消費しているものと思われる。
詳細は top コマンド等で確認できる。

今後

万が一落ちた場合に monit で MySQL の自動再起動、fail2ban によるブロッキング設定を行いたいが後ほど。

参考

MariaDB の InnoDB がぶっ壊れて起動できなくなったので復旧した

2019-04-04T03:18:36+09:00

はじめに

右往左往して復旧に6時間程度かかった。もうこりごりなので内容をざっくりまとめる。

手順（概略）

KUSANAGI（CentOS7）での手順。

sudo su
vi /etc/my.cnf.d/server.cnf
i

[mysqld]
innodb_force_recovery = 3

[esc] キーで vi 終了。

systemctl start mysqld
mysqldump -u root -p -x --all-databases > alldatabase.dump
systemctl stop mysqld
rm -rf /var/lib/mysql/*
yum remove -y MariaDB-devel MariaDB-client MariaDB-server
yum install -y MariaDB-devel MariaDB-client MariaDB-server
systemctl start mysqld
mysql -u root
UPDATE mysql.user SET password=password('password') WHERE user = 'root';
CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';
GRANT ALL ON db_name.* TO 'username'@'localhost';
flush privileges;
exit;
mysql -u root -p < alldatabase.dump

要点

innodb_force_recovery を 3 以下に設定しておくと InnoDB が壊れていても Read only でとりあえず起動出来るようになるっぽい
起動したら mysqldump でバックアップ。MariaDB を再インストール後に戻す
構成ファイルがいかれていたので /var/lib/mysql/ 配下を消しておく。（必要であれば設定ファイルは逃しておく）

原因

数日前に単純に MariaDB が落ちたことがあり、何かしら高負荷がかかっている可能性があるが、アクセス数も多くなく、環境である仮想ハードウェアの負荷も目立った様子は無い。できれば関係ログを追って探りたいところだが不明。

(2019.4.14 追記) 原因判明したので記事書きました

KUSANAGI で MySQL が頻繁に落ちる際の対処 - Crieit

参考

MySQLでInnoDB破損したときの復旧方法 - Qiita