レプリケーションを使わないMySQLの冗長化
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、DBMSチームの三谷です。 ヤフーでは多くのサービスでMySQLを利用しています。MySQLはヤフーを支える重要な技術の1つです。 私のチームではヤフーのさまざまなサービスのデータベースを集約して管理・運用しています。 集約することでコストの削減やノウハウの蓄積といった効果を生み出しています。 今回はこの集約環境の冗長化方法についてご紹介します。 集約環境の構成 集約環境ではマスターの冗長化にレプリケーションを利用せず、エンタープライズ向けの共有ストレージを利用したアクティブ・パッシブ型のHA構成を採用しています。 データファイルを共有ストレージに置き、どのマスターサーバーからでも同じデータに対してアクセスできるように
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
NFSのチューニング - 元RX-7乗りの適当な日々
何故か遅いNFSをチューニングするべく検証。 # 5MBの書き込みに27秒もかかるのはちょっと。。。 下記の検証結果が、全ての環境であてはまるわけではないため、ご参考程度までに。 検証時の構成 Linux(Xen domainU) ---NFS mount---> Linux(Xen domain0)Xenのバージョンは3.0.2(linux kernelは2.6.16)。 # NICのデバイスも所詮はXenによって仮想化されているので、それほど参考にならないかもなぁ・・・。 実験内容 設定をいじる server: /etc/exports client: autofs(/etc/auto.master) マウント先に、5MBのブロック(1ファイル)を書き込み # マウントポイントの名前は適当(^^; 設定1(syncのみ) server: /home/share client_hostn
nfs が umount できなかった。kill できないプロセスができちゃった。
えー結論からすると nfs を使ってるときには以下の３点に注意。 1. nfs client 側で umount せずに nfs server が動いているマシンを停止させない。 2. 上記状態になってしまったときに df -k など mount された状態を前提としたコマンドを実行させない。 3. 実行してしまって STAT が D の状態になってしまったプロセスが生まれてしまったらリブートしか解決方法はない。 です。では、何故こんな状態になってしまったか、ポカミスについて備忘録として情報公開です。 まず一番の原因として nfs client の接続を切らずに nfs server が動いているサーバを停止しちゃいました。これが前日にやったこと。バッチ処理で df -k の実行が走りました。 この通りロードアベレージが急上昇しました。df -k によって本来 mount されている nf
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
