元スレMySQL 総合 Part13
mysql覧 / PC版 / みんなの評価 : ☆
前へ
201 = :
>>193
そのシステムが命に関わるような場合、迷わずInnoDB
そのシステムが途中でデータ消えてもいいのでとにかく早くしたい場合MyISAM
（MyISAMでも一時間に一回バックアップとればそんなに問題にはならないでしょう。）
202 = :
InnoDBって遅いってイメージがあったけど、
実際違うなら、トランザクション使えるし、InnoDBの方がよくねぇ？
203 = :
>>201
このMyISAMならデータが消えるって、何を前提にしてんだ？
204 = :
>>203
>>201じゃないが、実際に両方とも運用していると、
MyISAMは一ヶ月に1回位、データがクラッシュする。
「XXXX marked as crashed」とかっていうエラーを吐き出す。
その場合は、REPAIRすると95％は直るが、5％はREPAIREも失敗する。
信頼性を犠牲にして速度を速めているのがMyISAMという認識でいる。
205 = :
MyISAMは確かに壊れやすいと思う。
読み出しと重ならなくても、更新が多い場合は避けるようにした。
追記だけとか、読むだけのテーブルなら良いと思うけど。
あんまり使ってないけど、MyISAMでもFixedなら壊れたことはないかな。
206 = :
っていうかDBで壊れやすいって致命的な欠陥じゃね？
車に例えれば、時々ブレーキが利かなくなることがあるってことだろ？
Oracleと比べるのは酷だが、どんなに機能が充実してOracleに近づいたといっても、
クリティカルなところ(お金に関わる部分や基幹業務、公共インフラ)では採用できないDBだな。
207 = :
当たり前です
208 :
かなり大きなvarcharを抱えているテーブルで文字検索をしたいのですが
全文検索用のインデックスを作って検索を高速化してくれるようなMySQLのアドオンってないでしょうか？
やっぱり正攻法でそういうことは全文検索用のソフトウェアにさせるべきなのでしょうか？
209 = :
>>206
それはちょっとちゃうな。
君はコンビニに買い物に行くとき、防弾チョッキ着て、護衛を付け、
遭難用携帯食料３日間分を念のため持って出かけるわけかい？
210 = :
>>206,209
どっちも両極端な意見すぎ！
特徴を理解した上で適材適所で使え。
211 = :
>>206
誰もMySQLの信頼性の話してない。
壊れやすいといっているのはMyISAMの話。
MyISAMの信頼性の話をしている。
MyISAMの信頼性が低いのは事実だが、
全体バックアップ＋バイナリログで普通に復旧できるので壊れてもすぐに復旧できる。
212 = :
話は変わるが、MyISAMってみんななんてよんでるの？
おれの周りでは、"ミィザム"とか"マイサム"とか
"エムワイアイエスエーエム"とかいろいろなんだが、
統一しないか？
213 = :
勲は俺のもの での統一でいいと思うけど
215 = :
いや、MyISAMだって、OSのクラッシュとかがなければ壊れないでしょ。フツー。
216 = :
IO弱いと壊れやすいんじゃね？
217 = :
mysql4.1から5.0のサーバーに移行しようとしてmysqldumpで全てのDBのバックアップを取ったんですが
なぜか新しい環境でユーザーは適用されているもののパスワードが反映されないです。
パスワード無しで接続できてしまい、逆に前の環境のパスワードを指定すると弾かれます。
mysql.userテーブル見てみたんですが、一応それぞれのユーザーに別々のパスワードは付与されているみたい。
なんでパスワードが適用されないんでしょう
教えてえろい人
220 = :
MySQLで問い合わせ時間を得たいのですがどうすればいいでしょうか？
mysql> select sum(1+2) as sum from dual;
+----------+
| sum |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
この場合、sumと問い合わせ時間(0.00 sec)を返してほしいです。
221 = :
>>220
度々似たような質問を見かけるんだが、
前スレにもあったように、問い合わせの時間が表示されるのは、mysql(クライアントプログラム)の独自機能であって、
mysqld(サーバー)の機能ではない。
よって時間を得たければ、例えばPerlなら、use Time::HiRes ; とすりなり、
PHPなら microtime(true) するしかないじゃないの。(てか俺はそうしてる。)
222 = :
mysql v4.0.20で文字コードにｕｊｉｓ使用のサーバから
Ｗｉｎ機でODBC接続してVB6でデータ取得について質問
MyODBC-3.51.06試したけどダメだった...
で myodbc-3.51.06-conv_ujis.zip 拾って使ってます。
HPからのリンク切れてるけどこれ使ってもいいの？
223 = :
あるサーバから別のサーバへMySQLのデータベースを
移動したいのですが、
.frm .MYD .MYI をそのまま移動させて
使用することってできるのでしょうか？
以前SQL文でエクスポートしてたんですが、
文字化けとかでかなり手こずった記憶がありまして、
できれば簡単な方法が良いなと思っています。
226 = :
>>223
同じバージョンならできる。
228 = :
レプリケーションについて教えてください。
レプリケーションの方式として、
1master-複数slave
という方式と
mutil-master
という方式があるみたいなのですが、
どういう場合にどちらを選ぶべきなのでしょうか？
229 = :
>>224
変わる。
もちろんインデックスのサイズとメモリ量による。
ログ系のテーブルなら、そんな複雑なインデックス貼らないだろうし(created_onとserver_idとstatusくらいか)
1000万件くらい大丈夫だと思うが。だめならパーティショニング。
それよりストレージエンジンをどうするか考えたほうがいいと思う。InnoDBかMyISAMかARCHIVEか。
>>228
シングルマスタはマスタがフェイルポイントになる。
マスタが死ぬと更新がまったく出来なくなる。
スレーブ1台をマスタに昇格させて復旧させる。
デュアルマスタはフェイルポイントがない。
auto_increment問題は、auto_increment_incrementとauto_increment_offsetを設定すれば大丈夫。
unique keyの重複したINSERTと、同一行の更新をどうするかが問題となる。
追加・更新のクエリを片方に寄せるというのも手。
3台以上のマルチマスタは手間の割にあまり利点ないので略。
230 :
デュアルマスタってのはお互いがお互いのマスタであり
スレーブであるっていう設定のこと？
んで，３台以上ってのはそれをリング状にしたってこと？
232 = :
うん
233 = :
4系でもいいと思うけどな
234 = :
>>230
そう。
あと、それぞれのマスタにスレーブをぶら下げたりもできる。
235 = 230 :
>>234
デュアルマスタまではやったことあるけど，
リング状ってのはまだやったことないな．
同じデータベースに対していどちらのマスタでも
更新ってのは怖くてやったことがない．
236 = :
>>228
俺もあまりよくしらないが、考えてみた。
まず、1マスタNスレーブの場合。
参照するたのslaveサーバが複数あるのだから当然、参照の負荷分散になる。
更新するためのmasterサーバも参照のアクセスと競合しないので、
負荷分散になるんだと思う。
>>229の指摘でマスタが壊れたら更新ができなくなるといっているが
それはmutil-masterも同じことだ。
確かに更新はできるが、データの不一致が起こるので、
むしろ障害発生時に更新をとめるような仕組み必要ではないか。
次、multi-masterの場合。
1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、
参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う。
更新は、あるサーバの更新が他のサーバ全てにレプリケーションされるわけだから、
更新については全く負荷分散にはならないんだと思う。
＞どういう場合にどちらを選ぶべきなのでしょうか？
結論としては、更新が比較的多い場合、1マスタnスレーブを考えるべき。
参照メインで更新が殆どない場合、mutil-masterということになるんだろう。
237 = :
覚醒せよ
238 :
助けて下さい。
mysqlで、間違えてデータベースを作ってしまいました。
その間違いを訂正しようとして、mysqlに登録したroot権限で
入っても、何をしたら良いかわからなくて。。
全部無かったことにしたくて、アンインストールしたりしましたが、
またインストールしたら間違えた設定のまま消えません。
完全に消去するには、どうすれば良いのでしょうか？
ちなみにosはfedora8です。
239 = :
>>212
まいあいさむ
241 = :
>>236
> >>229の指摘でマスタが壊れたら更新ができなくなるといっているが
> それはmutil-masterも同じことだ。
いいえ。
> 確かに更新はできるが、データの不一致が起こるので、
『データの不一致』はどのサーバ間をさしている?
> 次、multi-masterの場合。
> 1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、
> 参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う。
シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
# というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
> 更新は、あるサーバの更新が他のサーバ全てにレプリケーションされるわけだから、
> 更新については全く負荷分散にはならないんだと思う。
ここだけは合っている。
しかし、5.1の行レプリケーションを考慮した場合は間違いになる。
全般的にめちゃくちゃだ。
レプリケーションの仕組みをもうちょっと学んだほうがいい。
242 = :
>>241
>> 確かに更新はできるが、データの不一致が起こるので、
>『データの不一致』はどのサーバ間をさしている?
故障したサーバとそれ以外のサーバ。
たとえば、3台でリング上のレプリケーション組んでるとするだろ。
それぞれ、Ａ、Ｂ、Ｃとする。データの流れは、Ａ→Ｂ→Ｃ→Ａ...とする。
Ｂが壊れた場合、ＡからＣのデータの流れが途絶えるわけだから、
Ｃの更新はＡに反映されるが、Ａの更新はＣに反映されない。
>シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
># というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
mutil-masterの話なのに、この話がでるのが意味不明。説明してほしい。
＞しかし、5.1の行レプリケーションを考慮した場合は間違いになる。
そのとおりだね。間違いでした。
243 = :
レプリケーションって難しいねｗ
というか俺の頭が悪いのかorz
で、>>241に聞きたいのですが、
＞どういう場合にどちらを選ぶべきなのでしょうか？
に対する答えは、>>236さんの答えでは不十分ってこと？
そこらへんを解説きぼんぬ。
248 = :
>>242
>>『データの不一致』はどのサーバ間をさしている?
> 故障したサーバとそれ以外のサーバ。
> たとえば、3台でリング上のレプリケーション組んでるとするだろ。
> (略)
そうだね。だから3台以上のマルチマスタはあまり意味ないよ。
と、すでに229に書いた。
考えるならシングルマスタとデュアルマスタだけにした方がいいだろう。
『データの不一致』はデュアルマスタの場合にはどうなる?
3台以上のマルチマスタしか考えていない?
>>シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
>># というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
> mutil-masterの話なのに、この話がでるのが意味不明。説明してほしい。
あなたは『1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う』と書いているけど、増えないでしょ。1マスタNスレーブでマスタを参照してもかまわないわけだし。
1マスタ1スレーブの場合もデュアルマスタの場合も、参照は2台からできる。
>>243
> レプリケーションって難しいねｗ
いや、そんなに難しくないよ。5.0までのは、
マスタ: クエリを実行 -> 実行終了 -> 更新系のクエリなら(ちょこっと変えて)バイナリログに書く
スレーブ: マスタからバイナリログを取ってくる -> 実行
ってやってるだけだし。bin/mysqlbinlogで見ると分かるが。
> ＞どういう場合にどちらを選ぶべきなのでしょうか？
> に対する答えは、>>236さんの答えでは不十分ってこと？
不十分つーか、236のは過程もひどいし結論は意味不明すぎる。
シングルマスタとデュアルマスタの得失を229に書いといたから、自分の環境にあわせて選べばいい。
でも、228の人のレベルからするとシングルマスタの方がいいと思うが...デュアルマスタはフェイルポイント無くなるけど、代償も多いからハマりそう。
250 = :
208 名前：Trader＠Live![] 投稿日：2008/03/03(月) 23:24:21.29 ID:oVO24yUj
個人でも商売でもバイナリデータを直接操れよ
データベースやエクセルとかいうやつは初心者だよ
-----
と言われたんですが
みんなの評価 : ☆
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について