MySQLのmysqldump で --skip-opt を使うときに気をつけるただひとつのオプション - sakaikの日々雑感～(T)編
久々にMySQL関係でハマりました。原因は mysqldump です。実は数ヶ月前にも同じ現象で悩み、その時は深い調査しないまま対処療法をしてしまいました。今回、やはり技術者たるもの、しっかりと根本原因を追及しなければならないなと反省した次第です。 MySQL 5.0 以降の mysqldump では --opt オプションがデフォルトで有効となっています。これは以下の８つのオプションを一括して指定するオプションです。 --add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset この中で --extended-insert オプションがあることにより、レコードをコンマ区切りにして、できるかぎり一括してひとつのINSERT文
mysqldumpをエラーなく実行するために必要なopen_files_limitの値を調べる | guro_chanの日記
この間、多数のテーブルを持つデータベースのダンプファイル生成に失敗しているサーバを発見した。ダンプファイルの生成にはmysqldumpコマンドを用いているのであるが、 mysqldump: Got error: 23: Out of resources when opening file './***/***.MYD' (Errcode: 24) when using LOCK TABLES という具合にエラーメッセージを発して機嫌を損ねるのでどうもいけない。メッセージの内容もいまいちピンと来ないため途方に暮れながらGoogleで調べるとどうもテーブルの数が多すぎるのが怪しからん様子であることが分かった。このままではどうにも立ち行かないので解決策を探ると、 open_files_limit の値を増やせばよいということである。open_files_limit の値を調べると mysql>
mysqldumpとtimezoneと4.0 - いちいの日記
mysqldump の使い方が分かった気になってたら、大きな落とし穴がありました。 mysql4.0 -> 4.1/5.0 の大きな違いとしてcharの扱い、とくに文字数/バイト数の数え方の話があります。たとえば…、varchar(100)がvarchar(33)になっちゃうのでそのままだと文字数が足りない。なのでdump&importし直しでvarchar(100)にした。そしたら今度はkey lengthが1000byte超えちゃった、とかですね。 けど、もうひとつ、タイムゾーンの取扱いもおおきな変化なのでした。 具体的には、mysql4.0でtimestampにJSTな値を入れていたときに、それを4.1以降のmysqldumpでdumpしてimportしなおすと9時間ずれる、という問題が潜んでいました。 mysqldump が出力するヘッダみたいなの 前回に書いたように、mysql5
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mysqldumpで一行ずつのINSERT
rottel.net
