私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part13
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ☆
レスフィルター : (試験中)
>>193
そのシステムが命に関わるような場合、迷わずInnoDB
そのシステムが途中でデータ消えてもいいのでとにかく早くしたい場合MyISAM
(MyISAMでも一時間に一回バックアップとればそんなに問題にはならないでしょう。)
そのシステムが命に関わるような場合、迷わずInnoDB
そのシステムが途中でデータ消えてもいいのでとにかく早くしたい場合MyISAM
(MyISAMでも一時間に一回バックアップとればそんなに問題にはならないでしょう。)
InnoDBって遅いってイメージがあったけど、
実際違うなら、トランザクション使えるし、InnoDBの方がよくねぇ?
実際違うなら、トランザクション使えるし、InnoDBの方がよくねぇ?
>>201
このMyISAMならデータが消えるって、何を前提にしてんだ?
このMyISAMならデータが消えるって、何を前提にしてんだ?
MyISAMは確かに壊れやすいと思う。
読み出しと重ならなくても、更新が多い場合は避けるようにした。
追記だけとか、読むだけのテーブルなら良いと思うけど。
あんまり使ってないけど、MyISAMでもFixedなら壊れたことはないかな。
読み出しと重ならなくても、更新が多い場合は避けるようにした。
追記だけとか、読むだけのテーブルなら良いと思うけど。
あんまり使ってないけど、MyISAMでもFixedなら壊れたことはないかな。
っていうかDBで壊れやすいって致命的な欠陥じゃね?
車に例えれば、時々ブレーキが利かなくなることがあるってことだろ?
Oracleと比べるのは酷だが、どんなに機能が充実してOracleに近づいたといっても、
クリティカルなところ(お金に関わる部分や基幹業務、公共インフラ)では採用できないDBだな。
車に例えれば、時々ブレーキが利かなくなることがあるってことだろ?
Oracleと比べるのは酷だが、どんなに機能が充実してOracleに近づいたといっても、
クリティカルなところ(お金に関わる部分や基幹業務、公共インフラ)では採用できないDBだな。
かなり大きなvarcharを抱えているテーブルで文字検索をしたいのですが
全文検索用のインデックスを作って検索を高速化してくれるようなMySQLのアドオンってないでしょうか?
やっぱり正攻法でそういうことは全文検索用のソフトウェアにさせるべきなのでしょうか?
全文検索用のインデックスを作って検索を高速化してくれるようなMySQLのアドオンってないでしょうか?
やっぱり正攻法でそういうことは全文検索用のソフトウェアにさせるべきなのでしょうか?
>>206
誰もMySQLの信頼性の話してない。
壊れやすいといっているのはMyISAMの話。
MyISAMの信頼性の話をしている。
MyISAMの信頼性が低いのは事実だが、
全体バックアップ+バイナリログで普通に復旧できるので壊れてもすぐに復旧できる。
誰もMySQLの信頼性の話してない。
壊れやすいといっているのはMyISAMの話。
MyISAMの信頼性の話をしている。
MyISAMの信頼性が低いのは事実だが、
全体バックアップ+バイナリログで普通に復旧できるので壊れてもすぐに復旧できる。
話は変わるが、MyISAMってみんななんてよんでるの?
おれの周りでは、"ミィザム"とか"マイサム"とか
"エムワイアイエスエーエム"とかいろいろなんだが、
統一しないか?
おれの周りでは、"ミィザム"とか"マイサム"とか
"エムワイアイエスエーエム"とかいろいろなんだが、
統一しないか?
mysql4.1から5.0のサーバーに移行しようとしてmysqldumpで全てのDBのバックアップを取ったんですが
なぜか新しい環境でユーザーは適用されているもののパスワードが反映されないです。
パスワード無しで接続できてしまい、逆に前の環境のパスワードを指定すると弾かれます。
mysql.userテーブル見てみたんですが、一応それぞれのユーザーに別々のパスワードは付与されているみたい。
なんでパスワードが適用されないんでしょう
教えてえろい人
なぜか新しい環境でユーザーは適用されているもののパスワードが反映されないです。
パスワード無しで接続できてしまい、逆に前の環境のパスワードを指定すると弾かれます。
mysql.userテーブル見てみたんですが、一応それぞれのユーザーに別々のパスワードは付与されているみたい。
なんでパスワードが適用されないんでしょう
教えてえろい人
MySQLで問い合わせ時間を得たいのですがどうすればいいでしょうか?
mysql> select sum(1+2) as sum from dual;
+----------+
| sum |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
この場合、sumと問い合わせ時間(0.00 sec)を返してほしいです。
mysql> select sum(1+2) as sum from dual;
+----------+
| sum |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
この場合、sumと問い合わせ時間(0.00 sec)を返してほしいです。
>>220
度々似たような質問を見かけるんだが、
前スレにもあったように、問い合わせの時間が表示されるのは、mysql(クライアントプログラム)の独自機能であって、
mysqld(サーバー)の機能ではない。
よって時間を得たければ、例えばPerlなら、use Time::HiRes ; とすりなり、
PHPなら microtime(true) するしかないじゃないの。(てか俺はそうしてる。)
度々似たような質問を見かけるんだが、
前スレにもあったように、問い合わせの時間が表示されるのは、mysql(クライアントプログラム)の独自機能であって、
mysqld(サーバー)の機能ではない。
よって時間を得たければ、例えばPerlなら、use Time::HiRes ; とすりなり、
PHPなら microtime(true) するしかないじゃないの。(てか俺はそうしてる。)
mysql v4.0.20で文字コードにujis使用のサーバから
Win機でODBC接続してVB6でデータ取得について質問
MyODBC-3.51.06試したけどダメだった...
で myodbc-3.51.06-conv_ujis.zip 拾って使ってます。
HPからのリンク切れてるけどこれ使ってもいいの?
Win機でODBC接続してVB6でデータ取得について質問
MyODBC-3.51.06試したけどダメだった...
で myodbc-3.51.06-conv_ujis.zip 拾って使ってます。
HPからのリンク切れてるけどこれ使ってもいいの?
あるサーバから別のサーバへMySQLのデータベースを
移動したいのですが、
.frm .MYD .MYI をそのまま移動させて
使用することってできるのでしょうか?
以前SQL文でエクスポートしてたんですが、
文字化けとかでかなり手こずった記憶がありまして、
できれば簡単な方法が良いなと思っています。
移動したいのですが、
.frm .MYD .MYI をそのまま移動させて
使用することってできるのでしょうか?
以前SQL文でエクスポートしてたんですが、
文字化けとかでかなり手こずった記憶がありまして、
できれば簡単な方法が良いなと思っています。
>>223
同じバージョンならできる。
同じバージョンならできる。
レプリケーションについて教えてください。
レプリケーションの方式として、
1master-複数slave
という方式と
mutil-master
という方式があるみたいなのですが、
どういう場合にどちらを選ぶべきなのでしょうか?
レプリケーションの方式として、
1master-複数slave
という方式と
mutil-master
という方式があるみたいなのですが、
どういう場合にどちらを選ぶべきなのでしょうか?
>>224
変わる。
もちろんインデックスのサイズとメモリ量による。
ログ系のテーブルなら、そんな複雑なインデックス貼らないだろうし(created_onとserver_idとstatusくらいか)
1000万件くらい大丈夫だと思うが。だめならパーティショニング。
それよりストレージエンジンをどうするか考えたほうがいいと思う。InnoDBかMyISAMかARCHIVEか。
>>228
シングルマスタはマスタがフェイルポイントになる。
マスタが死ぬと更新がまったく出来なくなる。
スレーブ1台をマスタに昇格させて復旧させる。
デュアルマスタはフェイルポイントがない。
auto_increment問題は、auto_increment_incrementとauto_increment_offsetを設定すれば大丈夫。
unique keyの重複したINSERTと、同一行の更新をどうするかが問題となる。
追加・更新のクエリを片方に寄せるというのも手。
3台以上のマルチマスタは手間の割にあまり利点ないので略。
変わる。
もちろんインデックスのサイズとメモリ量による。
ログ系のテーブルなら、そんな複雑なインデックス貼らないだろうし(created_onとserver_idとstatusくらいか)
1000万件くらい大丈夫だと思うが。だめならパーティショニング。
それよりストレージエンジンをどうするか考えたほうがいいと思う。InnoDBかMyISAMかARCHIVEか。
>>228
シングルマスタはマスタがフェイルポイントになる。
マスタが死ぬと更新がまったく出来なくなる。
スレーブ1台をマスタに昇格させて復旧させる。
デュアルマスタはフェイルポイントがない。
auto_increment問題は、auto_increment_incrementとauto_increment_offsetを設定すれば大丈夫。
unique keyの重複したINSERTと、同一行の更新をどうするかが問題となる。
追加・更新のクエリを片方に寄せるというのも手。
3台以上のマルチマスタは手間の割にあまり利点ないので略。
デュアルマスタってのはお互いがお互いのマスタであり
スレーブであるっていう設定のこと?
んで,3台以上ってのはそれをリング状にしたってこと?
スレーブであるっていう設定のこと?
んで,3台以上ってのはそれをリング状にしたってこと?
>>228
俺もあまりよくしらないが、考えてみた。
まず、1マスタNスレーブの場合。
参照するたのslaveサーバが複数あるのだから当然、参照の負荷分散になる。
更新するためのmasterサーバも参照のアクセスと競合しないので、
負荷分散になるんだと思う。
>>229の指摘でマスタが壊れたら更新ができなくなるといっているが
それはmutil-masterも同じことだ。
確かに更新はできるが、データの不一致が起こるので、
むしろ障害発生時に更新をとめるような仕組み必要ではないか。
次、multi-masterの場合。
1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、
参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う。
更新は、あるサーバの更新が他のサーバ全てにレプリケーションされるわけだから、
更新については全く負荷分散にはならないんだと思う。
>どういう場合にどちらを選ぶべきなのでしょうか?
結論としては、更新が比較的多い場合、1マスタnスレーブを考えるべき。
参照メインで更新が殆どない場合、mutil-masterということになるんだろう。
俺もあまりよくしらないが、考えてみた。
まず、1マスタNスレーブの場合。
参照するたのslaveサーバが複数あるのだから当然、参照の負荷分散になる。
更新するためのmasterサーバも参照のアクセスと競合しないので、
負荷分散になるんだと思う。
>>229の指摘でマスタが壊れたら更新ができなくなるといっているが
それはmutil-masterも同じことだ。
確かに更新はできるが、データの不一致が起こるので、
むしろ障害発生時に更新をとめるような仕組み必要ではないか。
次、multi-masterの場合。
1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、
参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う。
更新は、あるサーバの更新が他のサーバ全てにレプリケーションされるわけだから、
更新については全く負荷分散にはならないんだと思う。
>どういう場合にどちらを選ぶべきなのでしょうか?
結論としては、更新が比較的多い場合、1マスタnスレーブを考えるべき。
参照メインで更新が殆どない場合、mutil-masterということになるんだろう。
助けて下さい。
mysqlで、間違えてデータベースを作ってしまいました。
その間違いを訂正しようとして、mysqlに登録したroot権限で
入っても、何をしたら良いかわからなくて。。
全部無かったことにしたくて、アンインストールしたりしましたが、
またインストールしたら間違えた設定のまま消えません。
完全に消去するには、どうすれば良いのでしょうか?
ちなみにosはfedora8です。
mysqlで、間違えてデータベースを作ってしまいました。
その間違いを訂正しようとして、mysqlに登録したroot権限で
入っても、何をしたら良いかわからなくて。。
全部無かったことにしたくて、アンインストールしたりしましたが、
またインストールしたら間違えた設定のまま消えません。
完全に消去するには、どうすれば良いのでしょうか?
ちなみにosはfedora8です。
>>212
まいあいさむ
まいあいさむ
>>236
> >>229の指摘でマスタが壊れたら更新ができなくなるといっているが
> それはmutil-masterも同じことだ。
いいえ。
> 確かに更新はできるが、データの不一致が起こるので、
『データの不一致』はどのサーバ間をさしている?
> 次、multi-masterの場合。
> 1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、
> 参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う。
シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
# というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
> 更新は、あるサーバの更新が他のサーバ全てにレプリケーションされるわけだから、
> 更新については全く負荷分散にはならないんだと思う。
ここだけは合っている。
しかし、5.1の行レプリケーションを考慮した場合は間違いになる。
全般的にめちゃくちゃだ。
レプリケーションの仕組みをもうちょっと学んだほうがいい。
> >>229の指摘でマスタが壊れたら更新ができなくなるといっているが
> それはmutil-masterも同じことだ。
いいえ。
> 確かに更新はできるが、データの不一致が起こるので、
『データの不一致』はどのサーバ間をさしている?
> 次、multi-masterの場合。
> 1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、
> 参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う。
シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
# というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
> 更新は、あるサーバの更新が他のサーバ全てにレプリケーションされるわけだから、
> 更新については全く負荷分散にはならないんだと思う。
ここだけは合っている。
しかし、5.1の行レプリケーションを考慮した場合は間違いになる。
全般的にめちゃくちゃだ。
レプリケーションの仕組みをもうちょっと学んだほうがいい。
>>241
>> 確かに更新はできるが、データの不一致が起こるので、
>『データの不一致』はどのサーバ間をさしている?
故障したサーバとそれ以外のサーバ。
たとえば、3台でリング上のレプリケーション組んでるとするだろ。
それぞれ、A、B、Cとする。データの流れは、A→B→C→A...とする。
Bが壊れた場合、AからCのデータの流れが途絶えるわけだから、
Cの更新はAに反映されるが、Aの更新はCに反映されない。
>シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
># というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
mutil-masterの話なのに、この話がでるのが意味不明。説明してほしい。
>しかし、5.1の行レプリケーションを考慮した場合は間違いになる。
そのとおりだね。間違いでした。
>> 確かに更新はできるが、データの不一致が起こるので、
>『データの不一致』はどのサーバ間をさしている?
故障したサーバとそれ以外のサーバ。
たとえば、3台でリング上のレプリケーション組んでるとするだろ。
それぞれ、A、B、Cとする。データの流れは、A→B→C→A...とする。
Bが壊れた場合、AからCのデータの流れが途絶えるわけだから、
Cの更新はAに反映されるが、Aの更新はCに反映されない。
>シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
># というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
mutil-masterの話なのに、この話がでるのが意味不明。説明してほしい。
>しかし、5.1の行レプリケーションを考慮した場合は間違いになる。
そのとおりだね。間違いでした。
windows+linux のクラサバなんだけどjavaで動かしている時って
mysqlの文字コードはsjisにしてる?それともutf8?
vistaだとutf8が4バイトらしいんだが・・
mysqlの文字コードはsjisにしてる?それともutf8?
vistaだとutf8が4バイトらしいんだが・・
MySQLに限ってはutf-8だと3byteが上限
They can be encoded with 8, 16, or 24 bits, as in utf8
They can be encoded with 8, 16, or 24 bits, as in utf8
>>242
>>『データの不一致』はどのサーバ間をさしている?
> 故障したサーバとそれ以外のサーバ。
> たとえば、3台でリング上のレプリケーション組んでるとするだろ。
> (略)
そうだね。だから3台以上のマルチマスタはあまり意味ないよ。
と、すでに229に書いた。
考えるならシングルマスタとデュアルマスタだけにした方がいいだろう。
『データの不一致』はデュアルマスタの場合にはどうなる?
3台以上のマルチマスタしか考えていない?
>>シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
>># というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
> mutil-masterの話なのに、この話がでるのが意味不明。説明してほしい。
あなたは『1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う』と書いているけど、増えないでしょ。1マスタNスレーブでマスタを参照してもかまわないわけだし。
1マスタ1スレーブの場合もデュアルマスタの場合も、参照は2台からできる。
>>243
> レプリケーションって難しいねw
いや、そんなに難しくないよ。5.0までのは、
マスタ: クエリを実行 -> 実行終了 -> 更新系のクエリなら(ちょこっと変えて)バイナリログに書く
スレーブ: マスタからバイナリログを取ってくる -> 実行
ってやってるだけだし。bin/mysqlbinlogで見ると分かるが。
> >どういう場合にどちらを選ぶべきなのでしょうか?
> に対する答えは、>>236さんの答えでは不十分ってこと?
不十分つーか、236のは過程もひどいし結論は意味不明すぎる。
シングルマスタとデュアルマスタの得失を229に書いといたから、自分の環境にあわせて選べばいい。
でも、228の人のレベルからするとシングルマスタの方がいいと思うが...デュアルマスタはフェイルポイント無くなるけど、代償も多いからハマりそう。
>>『データの不一致』はどのサーバ間をさしている?
> 故障したサーバとそれ以外のサーバ。
> たとえば、3台でリング上のレプリケーション組んでるとするだろ。
> (略)
そうだね。だから3台以上のマルチマスタはあまり意味ないよ。
と、すでに229に書いた。
考えるならシングルマスタとデュアルマスタだけにした方がいいだろう。
『データの不一致』はデュアルマスタの場合にはどうなる?
3台以上のマルチマスタしか考えていない?
>>シングルマスタでマスタを参照してもいいので、1台増える訳ではない。
>># というか、レプリケーションの時間差が許されない場面では普通はマスタを参照する。
> mutil-masterの話なのに、この話がでるのが意味不明。説明してほしい。
あなたは『1マスタNスレーブと比べると、参照のためのサーバが一台増えるわけだから、参照だけを考えると、1マスタnスレーブよりすぐれているんだと思う』と書いているけど、増えないでしょ。1マスタNスレーブでマスタを参照してもかまわないわけだし。
1マスタ1スレーブの場合もデュアルマスタの場合も、参照は2台からできる。
>>243
> レプリケーションって難しいねw
いや、そんなに難しくないよ。5.0までのは、
マスタ: クエリを実行 -> 実行終了 -> 更新系のクエリなら(ちょこっと変えて)バイナリログに書く
スレーブ: マスタからバイナリログを取ってくる -> 実行
ってやってるだけだし。bin/mysqlbinlogで見ると分かるが。
> >どういう場合にどちらを選ぶべきなのでしょうか?
> に対する答えは、>>236さんの答えでは不十分ってこと?
不十分つーか、236のは過程もひどいし結論は意味不明すぎる。
シングルマスタとデュアルマスタの得失を229に書いといたから、自分の環境にあわせて選べばいい。
でも、228の人のレベルからするとシングルマスタの方がいいと思うが...デュアルマスタはフェイルポイント無くなるけど、代償も多いからハマりそう。
208 名前:Trader@Live![] 投稿日:2008/03/03(月) 23:24:21.29 ID:oVO24yUj
個人でも商売でもバイナリデータを直接操れよ
データベースやエクセルとかいうやつは初心者だよ
-----
と言われたんですが
個人でも商売でもバイナリデータを直接操れよ
データベースやエクセルとかいうやつは初心者だよ
-----
と言われたんですが
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 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 ○
トップメニューへ / →のくす牧場書庫について