タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

技術:DBに関するis302622のブックマーク (10)

  • 省サーバ運用

    自己紹介 名前 小林 篤 ID:nekokak(ネコカク) DBIx::Skinny continued...

  • DRBD+heartbeat+LVM(on Fedora Core10)によるクラスタリング

    こんにちは、亀です。 今回は、PHPとかから少し離れて、サーバのクラスタリングのお話です。 ちょっと仕事で冗長化システムを組む必要があったので、せっかくなので記事にまとめました。 さて、ここで目指すのは、DRBDを使ったデータレプリケーションサーバ( Master / Slave 構成 )の自動フェイルオーバークラスタ( 非フェイルバック構成 )です。 ネットワーク構成としては、ルータから結ばれるLAN(eth0に接続)とは別に、eth1で1対1のLAN接続を行います。 また、heartbeatでのクラスタ構成後は、eth0に仮想IPとして192.168.1.100を割り振るようにします。 eth1の設定は、 # vi /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 HWADDR=00:00:00:00:00:00 ONBOOT

    DRBD+heartbeat+LVM(on Fedora Core10)によるクラスタリング
  • Heartbeatでかんたんクラスタリング(4):ミラーリングツール「DRBD」によるデータ保護 (1/3) - @IT

    1つの例として「SAN」(Storage Area Network)があります。データを格納するストレージ自体が冗長化されている製品も多いですし、サーバをSANに接続するためのHBA(Host Bus Adapter)を二重化することも可能ですが、コストもかさみます。 現在ならば、SCSIブロックをIP化してしまう「iSCSI」も選択肢として挙げられるでしょう。ですが最近までiSCSIは、「iSCSi接続を確立するためのイニシエータが不安定だ」などといわれることもありました。また、データを共有する「NFS」(Network File System)を用いてほかのサーバにデータを保存することもできます。しかし外部にデータを置くとなると、どうしても、その分コストも高くなってしまいます。 最もコストを抑える方法を考えた場合に浮上してくる選択肢がDRBDです。Heartbeatによるサービスの冗長

    Heartbeatでかんたんクラスタリング(4):ミラーリングツール「DRBD」によるデータ保護 (1/3) - @IT
  • HAクラスタシステム構築(Heartbeat+DRBD) - CentOSで自宅サーバー構築

    DRBDはマウントレベル(/home等)ではなく、デバイスレベル(/dev/VolGroup00/lvol0等)でデータの二重化を行うため、ハードディスク追加または、既存論理ボリュームサイズ縮小してDRBD用に空きの論理ボリュームを追加する。 ※空き論理ボリュームにはファイルシステムを作成しないこと [root@cl1 ~]# df ← マウント状況照会 Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 3428080 1557756 1693380 48% / ← 論理ボリューム(/dev/mapper/VolGroup00-LogVol00)に/が割当てられている /dev/sda1 101086 17832 78035 19% /boot tmpfs 127796 0 127796 0% /d

  • DRBD+Heartbeatでお手軽HA Cluster VA Linux Systems Japan

    サーバを運用する際の問題の一つとして故障時の対応があります。高価なシステムを構築すればストレージはSANで構築し、サービスのフェイルオーバーも高価な商用ソフトを導入することで実現することは可能です。しかしながら、「そこまでコストをかけて構築しなくても、、、」といった場合もあるかと思います。そのような場合の解決策の一つとして、編ではDRBD + Heartbeatというオープンソース・ソフトウェアを用いて、HA Clusterを構築する方法を解説します。以下、<host_m>と<host_s>という2台のサーバを用いた構成手順を紹介します。 DRBDとは、Distributed Replicated Block Deviceの略で、家WEBサイトは http://www.drbd.org/ になります。具体的にDRBDは何をするものか?というと、パーティション

  • [次世代DB編]DWHアプライアンスにサマリーテーブルを作ってはいけない

    RDBMSを使ってデータウエアハウス(DWH)を構築するとき、「サマリーテーブル」を作ることが多い。サマリーテーブルとは、既存のテーブルを結合したり集計したりした、分析用のテーブルである。派生テーブルや集約テーブル、データマートと呼ぶこともある。 広く使われてきたサマリーテーブルだが、最近注目されているDWHアプライアンス上には作らない方がよい。DWHアプライアンスの多くは、明細データを読み取って集計することを想定して設計されている。こうなると、サマリーテーブルのメリットが薄れ、逆にデメリットの方が大きくなるのである。 サマリーテーブルの二つの問題 サマリーテーブルを作ると、いったいどんな問題が起こるのか。大きく二つの問題が生じるだろう。 一つは、メンテナンスの負担が増すことだ。サマリーテーブルの作成はユーザーではなく開発側が行う。分析内容の変更、ユーザーの追加といった改善要望に一つひとつ

    [次世代DB編]DWHアプライアンスにサマリーテーブルを作ってはいけない
  • NoSQLを超えるSQLデータベース「VoltDB」。Cassandraとベンチマーク対決!

    「多くのOLTPデータベースは30年前の設計を基にしており、今日の“Webスケールな”データベースの負荷を想定していない。これら伝統的なデータベースは、処理時間の90%以上がログ、ロック、ラッチ、バッファ制御といったオーバーヘッドに費やされ、しかもそれらによって限られた性能やスケーラビリティしか実現できていない」 Ingresの開発者でありInformixのCTOなどデータベースベンダの要職を歴任したデータベース研究者の大御所、マイケル・ストーンブレイカー氏が開発したVoltDBはプレスリリースでこのように既存のリレーショナルデータベースの欠点を示した上で、インメモリデータベースをベースにこれらのオーバーヘッドを除去し、ACIDによるデータ一貫性を維持しつつ大きな性能向上とスケーラビリティを実現したと説明されています。 SourceForge.jpの記事「「NoSQL」を上回る性能を目指す

    NoSQLを超えるSQLデータベース「VoltDB」。Cassandraとベンチマーク対決!
  • HDDをSSDにしたらデータベースはどれだけ速くなるか? オラクルと富士通が実験

    リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか? オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました(参考「日オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」)。 ホワイトペーパーでは、HDDの代わり

    HDDをSSDにしたらデータベースはどれだけ速くなるか? オラクルと富士通が実験
  • SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ

    SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex

    SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
  • SQLiteのテストコードは4567万8000行! 本体のコードは6万7000行

    軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。体のソースコードは約6万7200行(67.2KSLOC、Kilo Source Lines of Code:空行やコメントを除いた行数)なのに対し、テストコードはなんと4567万8300行(45678.3KSLOC)だと紹介されているのです! これはテストコードが体の約679倍もの大きさだということになります。 100%のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang

    SQLiteのテストコードは4567万8000行! 本体のコードは6万7000行
  • 1