MySQLに纏わる10の都市伝説
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
mysqlで既存の状態からレプリケーション構築 - innodb編 - うまいぼうぶろぐ
webの情報を見てると、まずデータディレクトリをtarで固めて・・・というのを良くみかける。MyISAMのみならそれでもいいと思うけど、InnoDBを使用してるとちょっと不都合かなと思って調べた。 というのもInnoDBのデータ領域は設定した分だけ最初にディスクに作成されるので、数GByteに設定している場合、実際に使ってる実データは少なくてもtarで時間がかかってしまうから。 調べながら試行錯誤したら、mysqldumpを使うだけで出来た。ただし、この方法の場合、dumpを取る間に全テーブルにREAD LOCKを掛ける。master dataの取得さえ先にしとけば、--lock-all-tablesしなくてもいけそうだけど。 masterでの作業 全データのdumpを取得する。 $ mysqldump \ --all-databases \ --add-drop-database \ -
ＤＢ改造屋雑記
(7/3追記)以下の話題に加えて色々見つかったものも含めてディスクフル関連の問題は内部開発ツリーではとりあえず全部修正済みにできたので次かその次のリリースでは全部直ってると思います。(5.7,8.0共に) 今回は性能の話ではありません。MySQLがディスクフルで詰む可能性についてです。 とあるバグ(また新機能入れて共通パスを変更したせいで…既存に影響するのは入れなければバグ減るのに…)をきっかけに最近いろいろ調べていましたが、 一応情報共有したほうが良いと思うので可能と思われる限り共有します。 しかし、今後の対応は議論中でチームとして会社としての方針とは異なる可能性があるので、 現状を説明するに留めます。 しかしそもそも、ディスクフルまで使う容量設計は元来非常にマズいので 誰の環境も該当していないと思いますが、一応順を追って（遡って？）説明します。 とはいえ基本的な利用では問題は起きないは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
