タグ

mysqlに関するinfohackのブックマーク (65)

  • ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法

    こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー

  • blog.galaxies: Red Hat Linux 9からDebian GNU/LinuxへのMySQL DB移行

  • おボえとケよ - Linux 設定日記

  • Tagclick Blog: タグ検索で大文字・小文字を区別する仕様とその実装方法について(MySQL編)

    TagClickの加藤です。 Livedoor Knowledgeでこんな質問を見つけました。 「livedoor clip」にてアルファベット(大文字・小文字)のタグの表記について 実はTagClickにもスタート当時同様の制約がありました。その後修正して、今は「登録および表示は大文字、小文字を区別」、「検索時は大文字、小文字を区別しない」というタグの仕様になっています。分かりやすくいうと、 タグをつけるときは大文字・小文字をそのまま保存 タグクラウドなどでは、例えばGooglegoogleは別々に表示 タグ検索時はGoogleでもgoogleでも同じ検索結果になる ということです。多分ライブドアさんでもDBMySQLを使っていると思うので、参考までに当社の藪崎がおこなった解決策を紹介します(ここからは技術的なハナシ)。 MySQLはデフォルトでは大文字・小文字を区別しないた

    infohack
    infohack 2007/08/16
    BINARY属性
  • http://rails.office.drecom.jp/takiuchi/archive/206

    infohack
    infohack 2007/08/14
    コネクションのLostが発生した場合に自動的に再接続
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.7 日付および時間関数

    次に、日付関数の使用例を示します。 次のクエリーは、過去 30 日以内の date_col 値を含むすべての行を選択します。 mysql> SELECT something FROM tbl_name -> WHERE DATE_SUB(CURDATE(),INTERVAL 30 DAY) <= date_col; このクエリーは、将来の日付を持つ行も選択します。 通常、日付値が要求される関数では、日付時間値が受け入れられ、時間の部分は無視されます。 通常、時間値が要求される関数では、日付時間値が受け入れられ、日付の部分は無視されます。 現在の日付または時間をそれぞれ返す関数は、クエリー実行の開始時にクエリーごとに 1 回だけ評価されます。 つまり、NOW() などの関数が単一クエリー内で複数回参照されても、常に同じ結果が生成されます。 (設計上、単一クエリーにはストアドプログラム (スト

  • [MySQLウォッチ]第37回 文字コードに起因する問題は文字化けだけじゃない,ソート順とcollationの関係

    MySQLウォッチ]第37回 文字コードに起因する問題は文字化けだけじゃない,ソート順とcollationの関係 前回は,マルチバイト文字コードを使用しているユーザであれば陥りがちな「文字化け」をテーマに解説を行った。特に日では,複数の文字コードが存在するので,混乱を助長してしまう。 さて,文字コードの違いによる弊害は,文字化けという表示の問題だけではない。データベースは,データの蓄積と提供が重要な役割である。大量のデータを提供する際には,並べ替えが必要になる。実は,文字データの場合,文字コードによって,並びが変化することをご存知だろうか。今回は,ソート処理と文字列の関係を解説する。 ソート処理での文字コードの影響 文字には,大文字と小文字のように同じ文字ながら,単語や文書での位置によって体裁が変わる場合がある。また,海外では,地域によって,アルファベットの並びが異なったり,文字自体が

    [MySQLウォッチ]第37回 文字コードに起因する問題は文字化けだけじゃない,ソート順とcollationの関係
  • [MySQLウォッチ]第36回 文字化けのメカニズム

    文字コードの多様化とインターネットやクライアント-サーバーなどの分散環境の普及によって,文字化けトラブルの頻度が飛躍的に拡大した。特に Webシステムでは,WebブラウザとWebサーバー,プログラム(スクリプト)言語,そしてデータベースと文字化けが発生する要因が数多く存在する。 Webサーバー側の文字化けは,他のコラムにお任せすることとして,今回はMySQLの文字化けに関して解説する。 文字化けの仕組み 文字化けは開発者にとって悩みの種である。しかし,文字化けの仕組みを少しでも知っていれば,意外と簡単に解決できるものだ。このコラムで,ぜひその知識を学んでほしい。 MySQL 4.1の変更点 さて,MySQLにおいては,バージョン4.1のリリースを境に文字化けが起きることが非常に多くなった。では,バージョン4.1は,それ以前のバージョンと何が変わったのだろうか。そこに文字化けを解決するヒント

    [MySQLウォッチ]第36回 文字化けのメカニズム
  • InnoDBのflush_methodによる違い - フツーな日常

    パラメータで言うとinnodb_flush_method っていう奴。 ようはトランザクションログなどをディスクに反映するときにfsync(2)を使うか、そもそもファイルをopen(2)するときにカーネルのバッファをバイパスするようなオプションを使うかの違い。デフォルトだとfsyncdataになるため前者になるが、Linuxの場合O_DIRECTを指定することで後者の動作となる。 InnoDBはI/Oのバッファリングを独自に行うことが出来るので、OSが提供するキャッシュを切ってしまった方がメモリの無駄が少ない。 例によって使ったベンチマークはsysbench-0.4.8、MySQLは5.0.37 Threads fdatasync O_DIRECT 1 19.8 20.31 2 20.88 21.04 3 21.06 20.64 4 20.89 20.78 5 21.15 21.03 6

    InnoDBのflush_methodによる違い - フツーな日常
  • MySQL :: MySQL Certifications

  • MySQLノウハウ

    いろいろなからメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),

  • [ThinkIT] 第1回:MySQLって何だ? (1/2)

    MySQLデータベースは、LinuxWindows、HP-UX、OS/X、HP-UXAIX、Netwareを含む20種類以上のプラットフォーム上で動作するマルチユーザ・マルチスレッドのSQLデータベースです。 その一貫した高速性、堅牢性と使い易さから数多くの有名サイトでも利用され世界で最も人気のあるオープンソースデータベースとなっています。またMySQLデータベースは、オープンソースの標準的プラットホームであるLAMP(Linux/Apache/MySQL/PHP)に含まれています。 1995年にフィンランドのMichael WideniusによってMySQLデータベースが誕生しました。2000年にはMySQLの開発、有償サポート、商用ライセンスの販売をする会社としてスウェーデンにMySQL AB社が設立されました。多くのオープン・ソース・プロジェクトと異なり一社で全ての権利を保有して

  • はてなブログ | 無料ブログを作成しよう

    賃貸暮らしのわが家の地震対策【揺れから命を守る編】 以前のブログでも記載した、防災の優先順位に基づいて対策を進めています。まだ手をつけられていない部分もありますが、ある程度まとまってきたのでざっくりとご紹介していきます。 優先順位別に改善していっているため、今回は主に地震の揺れ対策がメインになります。…

    はてなブログ | 無料ブログを作成しよう
  • MySQL AB :: The 12 Days of Scale-Out :: Day Twelve

    Contact Sales USA - Toll Free: +1-866-221-0634 USA - From abroad: +1-208-327-6494 USA - Subscription Renewals: +1-866-830-4410 Latin America: +1 512 535 7751 UK: +44 845 399 1124 Ireland: +353 1 6919191 Germany: +49 89 420 95 98 95 France: +33 1 70 61 48 95 Sweden: +46 730 207 871 Benelux: +358 50 5710 528 Italy: +39 06-99268193 Israel: +358 50 5710 528 Spain & Portugal: + 34 933905461

  • [mixi]MASTER-MASTERレプリケーションについて - MySQL | mixiコミュニティ

    どなたかMASTER-MASTERレプリケーションの構成で サイトを運用されているかたいますか? いま現在、あるサイトでmysqlのmaster-master レプリケーションの導入を検討しているのですが、 もし経験者の方がいましたらアドバイスお願いします。 気をつける点として、AUTO_INCREMENTでの シーケンス発行があるのですが、それについては mysqlのドキュメントに以下のような事が書かれています http://dev.mysql.com/doc/refman/5.0/en/replication-auto-increment.html その他にも、私としてはトランザクション処理がどのように 行われるのか気にしています。MASTER-MASTER構成にした 場合は、トランザクション処理などサーバ間で シンクロナイズされて行われるのでしょうか? MASTER-MASTER構成

  • sarabande.info

    This domain name has been registered with Gandi.net. It is currently parked by the owner.

  • banned interdit verboden prohibido vietato proibido

    banned    interdit  verboden   vietato     prohibido    verboden  banned   vietato      interdit proibido   vietato     interdit      verboden      banned  prohibido

    infohack
    infohack 2007/06/25
    >以下の点が MySQL と異なるので萌え萌えです
  • MySQL互換のデータベース、MoSQLが登場 | スラド

    MySQL互換で日語のハンドリングを向上させたオープンソースのデータベースMoSQL(もえすきゅーえる)が登場しました。MySQLと異なる点は、 デフォルトの文字コードはUTF-8(5.0&5.1) (デフォルトでは)文字コードの自動変換は行なわない(5.1のみ) 文字コードの範囲外のバイト列でもそのまま格納。データが失われない(5.0&5.1) デフォルトでSennaを組み込んでいるため、高速な日語全文検索が可能(5.0のみ) ほとんどのエラーメッセージを日語にできる(5.0&5.1) などとなっています。またcharset指定の機能がないアプリケーションでもクライアントライブラリの文字コードを環境変数で指定することでデータベースに日語を格納出来るそうですが、あくまでアプリケーション依存なので出来ない場合もあります。 ちなみにマスコットキャラはイルカの「萌ちゃん」で、スウェーデン

  • フツーな日常 - MySQLのTips

    http://forge.mysql.com/wiki/Top10SQLPerformanceTipsというのがあったので、和訳してみる。 (11/23 追記)id:pekeqさんとsodaさんのコメントを受け一部更新 (4/27 追記と修正)id:hirose31さんの指摘を受け修正。あと元のサイトが構成変更していたので追従 クエリのパフォーマンスに関するTips(データベースのデザインとインデックスについても) EXPLAINを使ってクエリの実行プロファイルを取れ スロークエリログを使え(常に有効にしておけ!) GROUP BYを使っているか使えるなら、DISTINCTを使うな Insertのパフォーマンス バッチ処理によるINSERTとREPLACE INSERTの代りにLOAD DATAを使う LIMIT m,nは案外速くない 2000件以上のレコードに対してORDER BY RA

    フツーな日常 - MySQLのTips
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 17 レプリケーション

    スケールアウトソリューション - 複数のレプリカに負荷を分散して、パフォーマンスを向上させます。 この環境では、すべての書込みおよび更新がソースサーバーで実行される必要があります。 ただし、1 つまたは複数のレプリカで読み取りが行われる場合があります。 このモデルでは、(ソースが更新専用であるため) 書込みのパフォーマンスを向上させる一方で、レプリカの数の増加に伴って読取り速度を大幅に向上させることができます。 データセキュリティ - レプリカはレプリケーションプロセスを一時停止できるため、対応するソースデータを破損させることなくレプリカでバックアップサービスを実行できます。 アナリティクス - ライブデータはソースで作成できますが、情報の分析はソースのパフォーマンスに影響を与えることなくレプリカで実行できます。 長距離データ分散 - レプリケーションを使用すると、ソースに永続的にアクセス