元スレMySQL 総合 Part24
mysql覧 / PC版 / みんなの評価 :
前へ
151 :
主キーが設定されているテーブルに何故か空白のレコードが入るんだが
どうしたらいい？
152 = :
NULLも1つの値、2行入るならおかしいが
153 :
ロックについて質問。
READロックにすると、ロックを取ったスレッドも書き込めなくなる。
WRITEロックにすると、ロックを取ったスレッド以外は参照もできなくなる。
全スレッドから参照はできて、書き込みはロックを取ったスレッドしかできないようなロックの仕方はありませんか？
154 = :
ダーティーリードを許したいってこと？
155 = 153 :
まあ、そういうことになるのかな
書き込みはロックを取らないとできない、複数スレッドから同時に書き込んでデータがおかしくならないようにしたい
ただし書き込み処理に時間がかかるのでその間も読み込みはストールしないようにしたい、そんな感じです
156 = :
>>153
古いバージョンのマニュアルだけど、
http://dev.mysql.com/doc/refman/5.1/ja/innodb-transaction-isolation.html
の内容を理解して、MySQLがサポートしているトランザクション分離レベルでは要件を満たせないなら、
アプリ側で独自ロックをやるしかないね。
ただし、そのアプリの外側ではやり放題になるけど。
158 = :
抽出できる物は削除できる。
まずはその最新の10件をSELECTできるように、そして最新の10件以外を
SELECTできるようなればそれをDELETEに渡すだけだ。
って何の最新？
163 = :
>>162
> 「時間」という型はない
アスペなの？DATETIME使えばいいだろ。
164 = :
なんでもかんでもアスペアスペ言えば良いと思ってんじゃねーぞ
165 = :
時刻型ならあるが時間型はない
・・・とか言いたいんだろうか
166 = :
long int使えっててどっかに書いてあった
167 = :
>>163
あなたがエスパー能力の持ち主か
(ファミチキ下さい)
俺が思っている事を当ててみてくれ
168 = :
>>167
ファミチキ無いならケンタ喰えばいい
170 = :
MySQLってよりは、RDB全般的なことなのかもしれないけど、
レコードを削除するにあたって、
(1) delete文でレコードを物理削除する
(2) 物理削除はせずにupdateで削除フラグをONにするだけ
（後からまとめてバッチで物理削除）
のどちらを選ぶのが負荷的やパフォーマンス的にベターですか？
DBの用途はBtoC系Webサービスなんですが。
171 = :
DBによっては内部で同じことしてるのもあるし、、、
外部キーとか入り組んでてカスケードで消える物が多いとか
そう言う状況でも変わってくるだろう。
172 = :
個人的な好みで言うとレコードの削除は極力しないかな。
何か問題があった時データが存在していたほうが便利だし。
174 = :
slaveはmasterのバイナリログを見に行ってるだけだから、特に何もしなくてもいいよ。
slaveを再起動したときも、オプションにskip_slave_start = 1が入ってない限り自動的にレプリケーションが再開される。
slaveはmaster側のDB操作とか記憶されたバイナリログの位置を記憶してるから、masterやslaveが停止したところで記憶したログの位置から処理を初めてくれる。
そういえばskip_slave_start = 1指定するとログのロテートする都度、START SLAVE;実行するハメになるんだけど何かスマートな方法ってあるの？
175 = :
>>173
基本的には、174 が書いてる通り。
Master と切断されたら master-connect-retry(default:60sec) で設定された間隔ごとに
再接続を行う。現在の値は show slave status の Connect_Retry で確認できる。
error_log にもその際のメッセージが書かれてると思うし、show slave status でも出たはず
ログ:
[ERROR] Slave I/O: error connecting to master 'user@host:3306' - retry-time: 60 retries: 86400, Error_code: 1130
>>174
うちでは、skip_slave_start 設定してないし、
flush binary logs/ flush logs や reset master は使わないのでわからないのだが
skip_slave_start はトラブル時に勝手に再開しないように設定してる？
もしそうならば、ローテートしないようにするぐらいしかないんじゃないかな..
# slow_log/error_log のためにローテートしてるなら、5.5 以降の個別ローテートを検討で
176 = :
>>175
クラッシュした時とか勝手に再開されてデータの不整合起こらないように、、なんだけど特に運用する上での必須という訳じゃなさそうだしオフにしときます。
あざっす！
178 = :
レプリケーション本当に開始されてる？？
マスター側が再起動しても、少し待てばスレーブも同じPositionになるはずだけど。
エラーログ一度確認してみた方がいいんじゃない。
181 = :
お、おう。
182 = :
>>171-172
ありがとうございます。
参考になった。
とりあえず論理削除（削除フラグON）でいくことにします。
184 = :
宗教上の理由で使ってます。
185 = :
10年前亡くなったばあちゃんの遺言。
186 = :
家庭の事情
188 = :
>>182
パーティショニングはしとくことお勧め
189 = :
mysqlコマンドにつけるオプションと同じことを、
sqlスクリプトの中で指定することはできますか。
たとえば mysql --slient や mysql --comments と
同じような動作にさせたいとき、sqlスクリプトの
中で何かオプションを設定すれば、--silent や
--comments と同じ動作になる、みたいなことは
できますか。
setコマンドでできるなら、variable名を教えてください。
よろしくお願いします。
191 = :
健全なライセンスで、MySQLの作成者とgoogle社員がコミットしているMairaDBかな。
Perconaは使ってるの聞いたことが無い。性能いいみたいだけど、使ってる事例とかあんま聞かないから仕事じゃ使えないな・・・。
個人で遊ぶには面白そうだけど。
192 = :
MySQLではなくUNIX系の話になると思うのだけど助けてください
mysqldumpをパイプ付きで実行した時にエラー戻り値を正しく取りたいです
mysqldump -uhoge > backup.dmp でエラー発生
echo $? 2が表示
mysqldump -uhoge | gzip -c > backup.dmp でエラー発生
echo $? 0が表示
mysqldump -uhoge > gzip -c > backup.dmpだとエラー戻り値も
取れるしバックアップも取れているみたいなんですけど
これで大丈夫ですか？
|と>の違いがよく判ってないです
193 = :
shell も書かずに質問とな
194 = :
> mysqldump -uhoge > gzip -c > backup.dmp
こんな書き方出来る shell でもあるのかと思った。
195 = :
以前にデータベースを作成した人が倍数+1の長さでフィールドを作成しています。
sample_id int(1025) UNSIGNED
scaler_id int(513) UNSIGNED
特に問題はないのですが+1をすることに何かデータベースを使用する上で良いことがあったりするんでしょうか？
196 = :
1000桁のID･･･だと･･･？
197 = :
>>194
びっくりしてやってみた(bash)
backup.dbというファイルに未圧縮でダンプされる
gzipというファイル名の空ファイルが出来る
"-c"はmysqldumpへのオプションとして渡る (--complete-insertのalias)
そりゃそうだね
199 = :
namedパイプつかってばらして書いてもいいよ
みんなの評価 :
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [94%] - 2011/10/17 4:48
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について