mysqldサービスがec2サーバーで1日に1回停止する
環境の詳細：
Server: Amazon ec2 Linux
Web Server: Apache
Web Framework: Django with mod_wsgi
次に、mysql_err.logファイルで見つけました。
The InnoDB memory heap is disabled
120823 3:21:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120823 3:21:40 InnoDB: Compressed tables use zlib 1.2.3
120823 3:21:40 InnoDB: Using Linux native AIO
120823 3:21:41 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
120823 3:21:41 InnoDB: Completed initialization of buffer pool
120823 3:21:41 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120823 3:21:41 [ERROR] Plugin 'InnoDB' init function returned error.
120823 3:21:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120823 3:21:41 [ERROR] Unknown/unsupported storage engine: InnoDB
120823 3:21:41 [ERROR] Aborting
システムメモリがバッファプールにメモリを割り当てるのに十分ではないようです。 Amazon ec2 micro instanceを使用していたときに同じエラーが発生したため、small instanceに移動しました。数日間は正常に機能しますが、現在は1日に1回壊れています。そのための恒久的な修正はありますか？中規模のインスタンスに移動できますが、問題は修正されるかどうかです。 innodb_buffer_pool_sizeを減らす必要がありますが、推奨サイズはどれくらいですか？
cat /proc/meminfoの結果は次のとおりです（役立つ場合があります）。
MemTotal: 1697824 kB
MemFree: 125744 kB
Buffers: 109704 kB
Cached: 481408 kB
SwapCached: 0 kB
Active: 1212396 kB
Inactive: 266840 kB
Active(anon): 888192 kB
Inactive(anon): 76 kB
Active(file): 324204 kB
Inactive(file): 266764 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 4 kB
Writeback: 0 kB
AnonPages: 888144 kB
Mapped: 15604 kB
Shmem: 144 kB
Slab: 63752 kB
SReclaimable: 53680 kB
SUnreclaim: 10072 kB
KernelStack: 800 kB
PageTables: 16436 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 848912 kB
Committed_AS: 1417140 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 10988 kB
VmallocChunk: 34359725168 kB
DirectMap4k: 1748992 kB
DirectMap2M: 0 kB
OSバージョン（uname -a）：Linux ip-10-246-134-149 3.2.21-1.32.6.amzn1.x86_64 #1 SMP Sat Jun 23 02:32:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
ps auxコマンドをチェックして、サーバーのメモリが15MBしか残っていないことを確認しました。これらは、その時点で実行されているhttpdプロセスです。
free -mの結果
total used free shared buffers cached
Mem: 1657 1628 29 0 3 19
-/+ buffers/cache: 1605 51
Swap: 895 875 20
ps auxの結果
Apache 21123 0.1 1.2 394652 20464 ? S 19:35 0:06 /usr/sbin/httpd
Apache 21146 0.1 1.2 394280 20796 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21152 0.1 1.2 394284 21560 ? S 19:38 0:05 /usr/sbin/httpd
Apache 21155 0.2 1.4 396244 24528 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21156 0.1 1.1 392552 20344 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21157 0.1 1.1 394284 18884 ? S 19:38 0:05 /usr/sbin/httpd
Apache 21159 0.1 1.4 396200 25040 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21161 0.1 1.2 394856 21724 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21162 0.1 1.3 394864 22400 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21163 0.1 1.3 394860 22204 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21164 0.1 1.1 392560 19204 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21165 0.1 1.3 394832 22280 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21166 0.1 1.3 395276 22932 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21172 0.2 1.4 396320 24820 ? S 19:38 0:06 /usr/sbin/httpd
Apache 21174 0.2 1.7 400672 29452 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21178 0.1 1.4 400540 25304 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21179 0.2 1.6 400580 27856 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21184 0.1 1.7 400628 29320 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21185 0.1 1.6 397944 27292 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21186 0.1 1.5 397960 25648 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21187 0.1 1.7 400576 29120 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21191 0.1 1.4 400576 24400 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21193 0.1 1.4 400536 24940 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21194 0.1 1.5 400572 26096 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21203 0.1 1.6 400580 28808 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21206 0.1 1.7 400584 29732 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21207 0.1 1.6 400576 27940 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21224 0.1 1.2 400624 20768 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21225 0.1 1.6 400576 28468 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21226 0.1 1.6 400576 28048 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21228 0.1 1.4 400572 23880 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21237 0.1 1.5 400628 26124 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21265 0.1 1.6 400536 28592 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21276 0.1 1.2 400544 21456 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21277 0.1 1.3 400624 22676 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21278 0.1 1.6 400536 27360 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21282 0.1 1.4 400612 24996 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21292 0.1 1.4 400532 24780 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21302 0.2 1.2 400540 21332 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21303 0.1 1.3 400628 22228 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21305 0.2 1.2 400536 21116 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21306 0.1 1.3 400572 22380 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21307 0.1 1.1 397956 20056 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21308 0.1 1.2 400624 21520 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21319 0.1 1.1 400540 19468 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21320 0.1 1.3 400628 22712 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21335 0.1 1.0 400540 17236 ? S 19:39 0:05 /usr/sbin/httpd
Apache 21336 0.1 1.3 400628 22188 ? S 19:39 0:06 /usr/sbin/httpd
Apache 21352 0.1 1.1 394276 18972 ? S 19:40 0:04 /usr/sbin/httpd
Apache 21356 0.1 1.1 394280 19028 ? S 19:40 0:05 /usr/sbin/httpd
Apache 21358 0.1 1.1 394280 19004 ? S 19:40 0:05 /usr/sbin/httpd
Apache 21361 0.2 0.7 400452 12632 ? S 19:40 0:06 /usr/sbin/httpd
Apache 21610 0.2 1.6 400536 27660 ? S 19:46 0:06 /usr/sbin/httpd
Apache 21643 0.2 1.3 400156 23272 ? S 19:55 0:04 /usr/sbin/httpd
Apache 21647 0.2 1.0 400544 17556 ? S 19:57 0:05 /usr/sbin/httpd
Apache 21654 0.2 1.5 400188 26884 ? S 19:58 0:05 /usr/sbin/httpd
Apache 21719 0.3 1.9 400192 32264 ? S 20:14 0:03 /usr/sbin/httpd
Apache 21725 0.2 2.0 400044 35340 ? S 20:15 0:03 /usr/sbin/httpd
Apache 21738 0.0 0.8 257648 13792 ? S 20:26 0:00 /usr/sbin/httpd
誰かがそれについてhttpdプロセスがたくさんある理由を知ることができますか？
50％の使用可能なRAMを使用してテストします。
Innodb_buffer_pool_sizeを非常に小さくして、役立つかどうかを確認できます。
#/etc/my.cnf
innodb_buffer_pool_size = 1M
経験則として、innodb_buffer_pool_sizeを使用可能なRAMの低メモリテスト用に50％に設定します。これは、サーバーとすべてexceptMySQL InnoDB。RAMの量を確認してください。その後、InnoDBにその50％を使用します。
一度に多くのメモリ不足の設定を試すには：
より可能性の高い犯人は、ウェブサーバーなど、そのサーバー上にあるものです。
アパッチ？
Apacheや別のWebサーバーを使用していますか？その場合は、RAM使用量を減らしてください。たとえば、Apache confでは、以下のような低いRAM設定を検討してください。
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
そして、次のようにリクエストを制限します。
MaxRequestsPerChild 300
次に、Apacheを再起動します。
mod_wsgi：
Mod_pythonでApacheを使用している場合は、mod_wsgiでApacheに切り替えます。
Pympler：
それでも発生する場合は、おそらくDjangoが着実に成長しています。Pymplerでのメモリプロファイリングを試してください。Django
SAR：
1日に1回の失敗、次に1週間に1回の失敗のレポートは、毎日または毎週実行されるある種のcronジョブを指している可能性があります。たとえば、大量のRAMを消費するバッチプロセスや、データベースダンプなどがあります。
RAM使用して、RAM MySQLが死ぬ前の1時間のスパイクを探すには、優れたツールであるSARを見てください。 http://www.thegeekstuff.com/2011/03/sar-examples/
Innodb_buffer_pool_size = <メインメモリの<60-80％）を減らす必要があります）
Innodbエラーの解決策：
110603 7:34:15 [ERROR] Plugin ‘InnoDB’ init function returned error.
110603 7:34:15 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
110603 7:34:15 [ERROR] Unknown/unsupported storage engine: InnoDB
110603 7:34:15 [ERROR] Aborting
10603 7:34:15 [Note] /usr/sbin/mysqld: Shutdown complete
I moved the ib_logfile0 and ib_logfile01 to bak and start Mysql again. Now this time, it is working fine
[root@xxx mysql]# mv ib_logfile0 ib_logfile0-bak
[root@xxx mysql]# mv ib_logfile1 ib_logfile1-bak
ソース： http://www.onaxer.com/tag/error-plugin-innodb-init-function-returned-error/
他の人が言ったように、問題はRAMでシステムが不足していて、そのためMySQLが爆破しているようです。システムのメモリが使用されている場所を絞り込む方法データベースがダウンした状態から回復する方法。
collectd とそのプラグインを見てください。該当するものには、 プロセスプラグイン および メモリプラグイン があります。これらを使用すると、システムのメモリ使用量とそのほとんどを占めているプロセスを確認できます。
Djangoの実行方法に応じて、特定の数の要求のみを処理して終了するようにワーカープロセスを構成できます。そのようにして、アプリケーションで何らかのメモリリークが発生した場合、その数のリクエストを超えても持続しません。たとえば、 Gunicorn を使用する場合、 -max-requests オプションを使用できます。 500に設定すると、500リクエストを処理した後にワーカーが削除されます。
上記の統計コレクションと組み合わせることで、興味深いメモリ使用量の傾向がわかります。
データベースのダウンに関しては、MySQLが停止した場合に自動的に再起動されるようにプロセス監視を設定できます。 Ubuntuの最新バージョンのMySQLはUpstartを使用してまさにそれを行います。プロセスが停止すると、Upstartはすぐにプロセスを再開します。このビルトインを持たない別のディストリビューションを使用している場合は、 Supervisor をご覧ください。これで問題は解決しませんが、少なくともその影響は軽減されます。これは修正ではなく、何か問題が発生した場合にアプリケーションを実行し続ける方法と見なされるべきです。
似たような問題に巻き込まれてしまうと、ユーザーにこのDB接続の確立エラーというugいメッセージが表示されることに本当にイライラしました。私が見つけた正確な問題を解決する代わりに、 this repo が（一時的に）私にとって魅力のように動作します。その後、友人によってデバッグされ、彼はいくつかの設定変更でサーバーを微調整しました。しかし、私はまだこのスクリプトを10分ごとにcrontabに追加してから、サーバーがクラッシュしているかどうかを確認します（私の場合は、サーバーでVNCServerを実行するたびにクラッシュします）
新しいスワップスペースを追加して利用可能なRAMを増やすことも役立ちます。手順は here
/ swapfileは、次のように表示される使用可能なスペースよりも小さいサイズで作成してください。
df -h
たとえば、df- hの出力は次のとおりです。
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.8G 1.2G 6.3G 16% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 492M 12K 492M 1% /dev
tmpfs 100M 336K 99M 1% /run
そこで、2 Gを使用して作成しました
Sudo fallocate -l 2G /swapfile
そして、サービスを開始するだけです
Sudo /etc/init.d/mysql restart
お役に立てれば。ではごきげんよう。
この議論に答えが追加され、私のために働いたことがわかりました： https://www.digitalocean.com/community/questions/mysql-server-keeps-stopping-unexpectedly?answer=26016
_innodb_buffer_pool_size_の_my.conf_で32Mのような合理的なものに_/etc/mysql/my.cnf_の両方を行う必要があります。 Apacheによって開始される接続の数を減らすために_/etc/Apache2/mods-enabled/mpm_prefork.conf_を変更する必要があります。
_<IfModule mpm_prefork_module>
StartServers 3
MinSpareServers 3
MaxSpareServers 5
MaxRequestWorkers 25
MaxConnectionsPerChild 0
</IfModule>
_