Tritonn のホットバックアップ(とsync ３回伝説) - kazuhoのメモ置き場
Tritonn のホットバックアップ環境を構築しようと思って調査。結論から言うと 漢(オトコ)のコンピュータ道: MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup の「MyISAMをスナップショットでバックアップ」でよさそう。 確認したこととしては、 Tritonn の全文検索データは FLUSH TABLES しても fsync されない つまり sync (1) の呼び出しが必須 linux の場合 sync (1) は１回呼べば十分だと man に書いてある POSIX 的には何回呼んでも書き込みが完了してる保証はない ってあたり。実際に、FLUSH TABLES WITH READ LOCK して sync ３回呼んでから LVM snapshot とって、myisamchk と sennachk してみたけど、myisamchk
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
なぜ “skip-innodb is defined” って言われるの？
この記事をブックマークする : こんにちはタガヤです。 いろいろとキャリアを積んだボクでも、日々勉強することがたくさんあります。 それだけ問題が起きてるってことですけども。 いやー、トラブルシューティングって楽しいですｗ（ドMか？） さて今回見舞われたトラブルですが、 VineLinux4.2 に Tritonn をRPMでインストールして使ってます。 トランザクションが大目のテーブルには、InnoDBを使おうと思ったら、 InnoDBでCreateしても、作成されるテーブルはMyISAMになってしまいます。 mysql > SHOW INNODB STATUS; するとエラーメッセージが表示されます。 ERROR 1235 (42000): Cannot call SHOW INNODB STATUS because skip-innodb is defined skip-innodb
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
