tag:crieit.net,2005:https://crieit.net/tags/InnoDB/feed
「InnoDB」の記事 - Crieit
Crieitでタグ「InnoDB」に投稿された最近の記事
2020-04-06T19:55:49+09:00
https://crieit.net/tags/InnoDB/feed
tag:crieit.net,2005:PublicArticle/15812
2020-04-06T06:18:12+09:00
2020-04-06T19:55:49+09:00
https://crieit.net/posts/MariaDB-MySQL-innodb
MariaDB (MySQL innoDB) が急にダウンする際に行ったパラメーターチューニング
<h1 id="はじめに"><a href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB">はじめに</a></h1>
<p>処理が遅いアプリの改善を行った後、処理性能が改善されたものの、MariaDB が急に落ちる問題が頻発。<br />
落ちるたびにシステムが停止し悩まされたが、なんとか解決したので備忘録。</p>
<h1 id="結論"><a href="#%E7%B5%90%E8%AB%96">結論</a></h1>
<ul>
<li>アプリ側で処理数が上昇した事で、IO 負荷が高くなっていた事が根本原因。</li>
<li>ストレージの IOPS を考慮して innodb_io_capacity, innodb_io_capacity_max, innodb_read_io_threads, innodb_write_io_threads を可能な限り増やす。増やすと上昇値が平準化される。負荷が上がり innodb_log_file_size の上限を超えて落ちることが無くなる。</li>
<li>innodb_buffer_pool_size は可能な限り上げる。余裕を持たせ処理を平準化させる。</li>
<li>innodb_log_buffer_size も一定水準まで上げる。上の対処を行った場合でも、負荷が上昇するとこの数値次第で落ちる原因になる。</li>
</ul>
<h1 id="環境"><a href="#%E7%92%B0%E5%A2%83">環境</a></h1>
<div class="table-responsive"><table>
<thead>
<tr>
<th>項目</th>
<th>値</th>
</tr>
</thead>
<tbody>
<tr>
<td>筐体・メモリ</td>
<td>さくらVPS 16GB</td>
</tr>
<tr>
<td>ストレージ</td>
<td>SSD</td>
</tr>
<tr>
<td>用途</td>
<td>nginx PHP ウェブサーバー + DB サーバー</td>
</tr>
</tbody>
</table></div>
<h1 id="具体的な my.ini 設定値 (関連値含む)"><a href="#%E5%85%B7%E4%BD%93%E7%9A%84%E3%81%AA+my.ini+%E8%A8%AD%E5%AE%9A%E5%80%A4+%28%E9%96%A2%E9%80%A3%E5%80%A4%E5%90%AB%E3%82%80%29">具体的な my.ini 設定値 (関連値含む)</a></h1>
<pre><code>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
</code></pre>
<h1 id="経緯や補足など"><a href="#%E7%B5%8C%E7%B7%AF%E3%82%84%E8%A3%9C%E8%B6%B3%E3%81%AA%E3%81%A9">経緯や補足など</a></h1>
<ul>
<li>特定の処理タイミングでのみ落ちていた為、アプリ側の問題を疑ったが、単純な参照と更新を繰り返すだけの処理な為、アプリ側の問題はほぼなかった。</li>
<li>MariaDB そのものについての情報が少ない。MySQL の情報はそこそこある為、適宜参考にする。</li>
<li>用いている MariaDB 10 は MySQL 5.6, 5.7 両バージョンをベースとしたキメラで若干ややこしい。</li>
<li>監視ツールの <a target="_blank" rel="nofollow noopener" href="https://soudai.hatenablog.com/entry/innodb">Mackerel の MySQL プラグイン</a>が役立った。知識がなくとも何かが制限を超えたような事が見て取れるので当たりが付けられた。</li>
<li>innoDB Checkpoint Age (Uncheckpointed) が急激に上昇し MariaDB が落ちていた。当初は innodb_log_file_size を上げて解決を図った。</li>
<li>多少ライフタイムが伸びたが、問題の根本は IO パフォーマンスにある為、上記は本質的な解決策にならず同様の問題が発生していた。</li>
<li>IO パフォーマンスはあくまで設定次第であり、物理側の IOPS に併せて勝手にスケーリングされる訳ではない。</li>
<li>ストレージが HDD では対処不能だったので SSD で助かった。</li>
<li>上記パラメーターが最善値であるか不明。安定し始めてから1週間程度な為、再調整の可能性あり。</li>
</ul>
<h1 id="参考"><a href="#%E5%8F%82%E8%80%83">参考</a></h1>
<ul>
<li><a target="_blank" rel="nofollow noopener" href="https://www.infiniteloop.co.jp/blog/2013/08/mysql-tuning-cacti-system/">これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(システム編) | 株式会社インフィニットループ技術ブログ</a></li>
<li><a target="_blank" rel="nofollow noopener" href="http://hiroi10.hatenablog.com/entry/20151210/1449731029">MySQL関連のパラメータ(主にInnoDB)について - hiroi10のブログ</a></li>
<li><a target="_blank" rel="nofollow noopener" href="ashitanosora.doorblog.jp/archives/37138751.html">MySQLのIOキャパシティについて : しがないエンジニアのつぶやき</a></li>
</ul>
sola
tag:crieit.net,2005:PublicArticle/14902
2019-04-04T03:18:36+09:00
2019-05-09T21:31:39+09:00
https://crieit.net/posts/MariaDB-InnoDB
MariaDB の InnoDB がぶっ壊れて起動できなくなったので復旧した
<h1 id="はじめに"><a href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB">はじめに</a></h1>
<p>右往左往して復旧に6時間程度かかった。もうこりごりなので内容をざっくりまとめる。</p>
<h1 id="手順(概略)"><a href="#%E6%89%8B%E9%A0%86%EF%BC%88%E6%A6%82%E7%95%A5%EF%BC%89">手順(概略)</a></h1>
<p>KUSANAGI(CentOS7)での手順。</p>
<pre><code>sudo su
vi /etc/my.cnf.d/server.cnf
i
</code></pre>
<pre><code>[mysqld]
innodb_force_recovery = 3
</code></pre>
<p>[esc] キーで vi 終了。</p>
<pre><code>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
</code></pre>
<h1 id="要点"><a href="#%E8%A6%81%E7%82%B9">要点</a></h1>
<ul>
<li><code>innodb_force_recovery</code> を 3 以下に設定しておくと InnoDB が壊れていても Read only でとりあえず起動出来るようになるっぽい</li>
<li>起動したら mysqldump でバックアップ。MariaDB を再インストール後に戻す</li>
<li>構成ファイルがいかれていたので <code>/var/lib/mysql/</code> 配下を消しておく。(必要であれば設定ファイルは逃しておく)</li>
</ul>
<h1 id="原因"><a href="#%E5%8E%9F%E5%9B%A0">原因</a></h1>
<p>数日前に単純に MariaDB が落ちたことがあり、何かしら高負荷がかかっている可能性があるが、アクセス数も多くなく、環境である仮想ハードウェアの負荷も目立った様子は無い。できれば関係ログを追って探りたいところだが不明。</p>
<h2 id="(2019.4.14 追記) 原因判明したので記事書きました"><a href="#%282019.4.14+%E8%BF%BD%E8%A8%98%29+%E5%8E%9F%E5%9B%A0%E5%88%A4%E6%98%8E%E3%81%97%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%98%E4%BA%8B%E6%9B%B8%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F">(2019.4.14 追記) 原因判明したので記事書きました</a></h2>
<p><a href="https://crieit.net/posts/KUSANAGI-MySQL">KUSANAGI で MySQL が頻繁に落ちる際の対処 - Crieit</a></p>
<h1 id="参考"><a href="#%E5%8F%82%E8%80%83">参考</a></h1>
<ul>
<li><a target="_blank" rel="nofollow noopener" href="https://qiita.com/skouno25/items/71174c959abe435223ab">MySQLでInnoDB破損したときの復旧方法 - Qiita</a></li>
</ul>
sola