Please note that these are old versions. New releases will have recent bug fixes and features! To download the latest release of MySQL Community Server, please visit MySQL Downloads.
SH2 @sh2nd 個人的にそうなんだろうなあと思っていたことが書いてあって、とても腑に落ちた記事 / how oracle prevent "partial write" | Oracle Community https://t.co/nHcmvh5ZSA 2014-05-18 13:21:43 SH2 @sh2nd MySQLのinnodb_doublewrite、PostgreSQLのfull_page_writesのような、データブロックが半分しか書かれていない事態を想定した処理は、Oracle DatabaseはALTER TABLESPACE BEGIN BACKUPのときにのみ行う 2014-05-18 13:26:55 SH2 @sh2nd なのでサーバクラッシュ時にデータブロックが壊れていて、REDOを適用しただけでは直せないことがある。ただその場合Oracle Dat
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
I don’t like stupid benchmarks, as they waste my time. I don’t like stupid marketing, as it wastes my time too. Sometimes I succumb to those things, and now in return I want to waste your time a bit. So, this MemSQL thing, written by some smart guys has been making rounds in press and technical community. Centerpiece of all the communication was: “MemSQL, the database they have developed over the
Membrain The Smart Memcached, Optimized for Flash Memory A software cache is often used, standalone or in front of a database, to increase application performance. Memcached is the most widely-used software cache, powering many high-volume web sites. But traditional memcached has a dark side also shared by the many NoSQL databases available today. With all of them, you need to keep your data in DR
仕事の合間に雑記です。またMySQLに関する記事です。Fusion-IOをMySQL DBマスタに使う時はスレーブ(こっちもFusion-IO)が耐えられるか検証した方が良いよって話。 おれが担当しているシステムは他のシステムの更新情報をかき集めてまとめるようなシステムです(あいまいな説明ですみません)。早い話、更新系の処理がかなり多いです。 更新処理が多いときにデータベースに施すテクニックの一つにデータ分割があると思いますが、マスタを分割しまくってサーバを何十台もラッキングして運用するのは骨でした。そこでioDriveの力を借りることにしました。ioDriveの力でDBを数台に集約してしまおうと。一応説明しておくとioDriveとはFusion-IO社のプロダクトで、PCIe接続の超高性能ストレージです。詳しくは下記のリンクを参照。 http://www.fusionio.com/pla
Apple improves iCloud for Windows, kills iTunes Among the changes to the widely used application are support for physical security keys, dark mode, and an improved user interface. Windows 11 Insider Previews: What’s in the latest build? Get the latest info on new preview builds of Windows 11 as they roll out to Windows Insiders. Now updated for Build 26052 for the Canary and Dev Channels and Build
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
こんにちは。パートナーサービス部の加藤和良です。 2008年末に、mixi の年末年始対策について紹介しました。今回は、ここ数年の年末年始対策の歩みと、今年の対策について紹介したいと思います。実をいうと、設計も実装も自分じゃなかったりするのですが、このまま歴史に埋もれていくのも悲しいので、関係各所に取材してみました。 2008年末をふりかえる まずは、2008年末をふりかえってみましょう。 あのころはまだ mixi の機能も少なく、年末年始の負荷は主に日記に集中していました。そこで当時は ID Generator の改善 - mod_perl をあいだにはさんで MySQL への接続本数を減らす 最新情報DBへの書き込みを非同期に - Q4M をつかって負荷を時間軸で分散する という2つを日記に実装したのでした。 しかし、2008年末から2009年のお正月にかけて、mixi はまたも日記に
Today I have uploaded Q4M (a Queue for MySQL) 0.6, which is basically a performance-improvement from previous releases. Instead of using pread's and a small user-level cache, Q4M (in default configuration) now uses mmap for reads with a reader/writer lock to improve concurrency. I also noticed that it would be possible to consume a queued row in one SQL statement. SELECT * FROM queue_table WHERE q
q4m の configure のオプション変更によってどの程度パフォーマンスに違いが出るのか比較してみた。 Intel(R) Xeon(TM) CPU 2.80GHz x 4 CPU OS : Debian(Etch) まずは、default 状態。 ./configure --with-mysql=/home/kameid/mysql-5.1.30/ --prefix=/usr/local/mysql 暗黙的に、以下のオプションを指定していることになる。 --with-sync=yes commit to disk at checkpoints (default) --with-delete=pwrite use pwrite for row deletions (default) t/05-multireader..........................ok 1/4 Mul
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く