タグ

MySQLに関するdssのブックマーク (9)

  • tweets.zipをMySQLに突っ込んでSQLを学ぶ(導入編) · さよならインターネット

    April 4, 2013 Twitterの過去ログが落とせるようになったので SQLに学ぶには丁度いいや。ということで カジュアルにOSX上でhomebrewを使ってMySQLに入れてみました。 MySQL ver.5.6 (homebrew install) OS / OSX 10.8.3 なにはともあれアーカイブをダウンロード Twitterの個人設定っぽいところから ポチポチするとダウンロードリンクが貼られたメールが送られてくるので ポチポチしてtweets.zipをダウンロード。 tweets.csvを探す tweets.zipを解凍すると、中身がこんな感じに出てきて index.htmlをブラウザで開くと、過去のツウィートが見れたりします。 時間泥棒なのでおすすめしません そして、tweets.csvが目的のファイルで、中身を開くと "tweet_id","in_reply_t

  • 既存のMySQLサーバからRDSインスタンスへの移行をテストする - サーバーワークスエンジニアブログ

    こんにちはインフラエンジニアの柳瀬です。 今回の内容は少しエントリー向けの内容になるかと思いますが、既存環境のMySQLからRDSへ移行するテストについて記載したいと思います。 オンプレミスの環境でMySQLを使用されている方は多くいらっしゃるかと思いますが、そういった方がRDSへ移行される事を検討した際に何かしらの参考になりましたら幸いです。 今回はEC2上のCentOSにMySQLをインストールして10GBのテストデータを投入しました。 こちらのデータをRDSに移行したいと思います。 ※RDSデータベースの作成方法はこちらのリンクをご覧頂けると分かりやすいと思います。 まず考える事がmysqldumpコマンドの--all-databasesオプションを使用して一気に移行する事ですね! これを実施すると以下のようになります。 # mysqldump -u root -x --all-da

    既存のMySQLサーバからRDSインスタンスへの移行をテストする - サーバーワークスエンジニアブログ
    dss
    dss 2011/10/24
  • (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場

    InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近1秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー

    (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
    dss
    dss 2009/10/29
  • レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ

    MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台+1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う!」「ここがおかしい!」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基構成、方針 2台+1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ
    dss
    dss 2009/10/24
  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

  • 限界までMySQLを使い尽くす!!

    どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値(16MBなど)に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは

    限界までMySQLを使い尽くす!!
    dss
    dss 2009/05/20
  • Yahoo!オークションでのMySQL 冗長化技術

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはオークション事業部プラットホーム技術のチャックです。 オークションでは一部サービスに RDBMSMySQL を使ってサービスをご提供させていただいております。 オークションでは多くのお客様よりアクセスを頂いておりますので、大量の更新、参照の処理速度に優れた MySQL を選択し、お客様にストレスなくサービスをご利用いただけるよう 日々業務に取り組まさせていただいております。 しかし、精密機器には故障がつきもので、サービス運用の観点からは 「機器が故障するのはしかたない、しかしそれをいかに早く復旧させるか」 といったことを念頭に入れております。 実際には、障害が起こってから復旧させるのではなく、障害が発生した場合に

    Yahoo!オークションでのMySQL 冗長化技術
  • JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2008年12月22日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり 今年のBlack Hat Japanには、はせがわようすけ氏が「趣味と実益の文字コード攻撃」と題して講演され話題となった。その講演資料が公開されているので、私は講演は聞き逃したが、資料は興味深く拝見した。その講演資料のP20以降には、「多対一の変換」と題して、UnicodeのU+00A5(通貨記号としての¥)が、他の文字コードに変換される際にバックスラッシュ「\」(日語環境では通貨記号)の0x5Cに変換されることから、パストラバーサルが発生する例が紹介されている。 しかし、バックスラッシュと言えばSQL

  • Comparison of Oracle, MySQL and PostgreSQL DBMS

    CONTENTS: 1. General consideration 2. Elementary features 3. Transactions 4. Programming in DB 5. Administration 6. Portability and Scalability 7. Performance and VLDB 8. Application development and interfaces 9. Reliability 10.Commercial issues 1. GENERAL CONSIDERATION: ---------------------------------------------------------------------------------------------------- Category P

  • 1