MySQLのレプリケーションでありがちな10の問題 | Yakst
レプリケーションの問題でよくある10パターン。 1) セッションのみで有効なバイナリログ sql_log_bin = 0を設定すると、そのセッション内でバイナリログを無効にできる。つまり、マスタのセッション内で実行したDMLやDDLは、スレーブにはレプリケーションされない。 マスタでバイナリログをオフにする。 mysql> set sql_log_bin = 0 ; Query OK, 0 rows affected (0.00 sec) reptestデータベースにテーブルを作成してみる(マスタ上で実行)。 mysql> create table reptest(ID int) ; Query OK, 0 rows affected (0.01 sec) mysql> show tables ; +-------------------+ | Tables_in_reptest | +-
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
MySQLにおけるスレーブのマスターへの昇格の手順メモ - shimxmemo
ちょっとやる機会があったのでメモ。 前提 サーバA（元々マスター。現スレーブ。新サーバと交換した） サーバB（元々スレーブ。昇格して現マスター） サーバC（スレーブ） ※my.cnfにはMasterの情報は書かない派。 サーバAを再度マスターに、サーバBをスレーブに落とす。 旧サーバA、サーバB、Cともに稼働年数同じぐらいで、「逝くときはぁ一緒だよーっ☆」されても困るので マスターに更新がかからないように、プログラムなど止めておく 手順 # サーバBのプロセスが流れていないか確認 svB# mysql mysql> SHOW PROCESSLIST; # 念の為サーバBの更新停止 mysql> FLUSH TABLES WITH READ LOCK; ※ロックが外れるのでmysqlから出ない事。 mysql> SHOW MASTER STATUS\G;; ※Fileの値とPositionの
MySQL 異なるストレージエンジン間のレプリケーションをスムーズに行う | QK
どもです。InfiiDBの最終章は、色々とトラブルがあって検証中です。もすこしで解決しそうなので、その時になったらまた記載させていただきます。ごめんなさり・・。今回は、そのトラブルの一つであった、「異なるストレージエンジン間のレプリケーション」の部分の話をさせてください。 異なるストレージエンジン間のレプリケーションって何？ つまり以下のような構成のレプリケーションのことです。 ちょっと前回の「InfiniDB でリアルタイムDWHを作る PART3 ～驚速DWHの構築」のBLACKBOXの部分の話の種明かしをしてしまうと、リアルタイムのしくみは、このフェデレーションによる透過的なテーブル更新を利用してDWHに書き込んでしまえ！という話だったのです。実は今のところ、この試みはさまざまな問題があり、うまいこと話が進まない状態なので今現在は、ちゃんと説明できる状態にはなっておりません。すみませ
PDOにてMaster&Slaveのコネクションを操作するクラス(PHP)
皆様、ご無沙汰しております。笹亀です。 いよいよきたる、9/10に新しいiPhone5 S(仮名)が発表される予定ということで、iphone4を使っている自分は今回のタイミングで変更する予定なので、いまから発表が楽しみです。 さて、本日はフレームワークなどを利用している場合などであれば、あまり使用することはないですが、PDOを利用したレプリケーションしたデータベースのコネクションを切り分ける方法をご紹介したいと思います。PHPでも様々なフレームワーク（symfony,Cake,ZendFramwork）を使い開発をされるようになってきており、あまりレプリケーションの切り分けを考える必要がなくなってきておりますが、切り分けを行う方法（考え方）という視点で見ていただけますと幸いです。 ※尚、ご使用される場合は自己責任でお願い致します 概要について レプリケーションのコネクションを切り分けること
【MySQLウォッチ】第7回 大規模システムを支えるMySQLのレプリケーション機能：ITpro
このところ楽天をはじめとして，MySQLを活用した大規模な事例が増えている（関連記事）。このような大規模，かつサービス停止の許されないシステムを支えているのが，MySQLのレプリケーション機能である。 「レプリケーション」とは，対象物とまったく同じ物を製作する処理だ。同じような意味に「ミラー」があるが，意味するところは物理的なコピーである。「レプリケーション」は，論理的な複製であり，対象物の全体や一部といった範囲を限定できる点が異なる。 このような機能は，大がかりな準備と高度な技術が必要と考えている方も多いだろう。しかし，MySQLのレプリケーション機能は，非常に簡単に利用することができる。今回は，現行バージョンでも利用可能なレプリケーション機能を解説する。 Masterの更新がSlaveに反映される MySQLのレプリケーション機能は，MasterとSlaveに役割が分かれる（図1[拡大
レプリケーションを使わないMySQLの冗長化
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、DBMSチームの三谷です。 ヤフーでは多くのサービスでMySQLを利用しています。MySQLはヤフーを支える重要な技術の1つです。 私のチームではヤフーのさまざまなサービスのデータベースを集約して管理・運用しています。 集約することでコストの削減やノウハウの蓄積といった効果を生み出しています。 今回はこの集約環境の冗長化方法についてご紹介します。 集約環境の構成 集約環境ではマスターの冗長化にレプリケーションを利用せず、エンタープライズ向けの共有ストレージを利用したアクティブ・パッシブ型のHA構成を採用しています。 データファイルを共有ストレージに置き、どのマスターサーバーからでも同じデータに対してアクセスできるように
MYSQLレプリケーション設定 - エーエイチレフ linuxサーバー技術情報
MySQLのインストールが終了した２台がある状態より設定を開始します。 マスターとスレーブの２台がある状態からスタートです。 事前準備 事前に２台のサーバーのデータが同じである必要があります。 mysqldump等でダンプを行い、データベースが完全に同じ状態とします。 マスターの設定 設定ファイルの編集 vi /etc/mysql/my.cnf 以下のように編集 server-id = 1 ↓ server-id = 18 (←ユニークな適当な数字へ変更) また以下を設定ファイル内のどこかに追記(ある場合はそのままでOK) log-bin = mysql-bin アカウントの作成 レプリケーション用のアカウントをマスターに作成する。 このアカウントはREPLICATION SLAVE権限を持っている必要がある 以下はすべての接続を許す’repl’ユーザーを作成する例。(グ
MySQL レプリケーションのセットアップ手順 - わくわく技術ランド
想定していること † MySQL5.0 MySQLがすでに稼動中。レプリケーションの設定はしていない 今回MySQLをもう一台増やして2台構成とし、master、slaveの構成にする ※今回と状況が異なる場合は、MySQLのリファレンスマニュアルを読むといいです。 ↑ 1. レプリケーション用ユーザを作成する † レプリケーション用ユーザを作成する 作成するユーザーはスレーブがマスタのバイナリ ログを読み込むときに接続するユーザーとなる。 既存のユーザーでもレプリケーションは可能だが、ユーザ名とパスワードが master.info ファイル内にテキストで保存されるため、安全のためレプリケーションプロセスにだけ権限があるユーザを作成する 設定例(マスタのほうに設定) 192.168.23.0/24 内のネットワークで許可 ユーザー名：repl パスワード：slavepass mysql >
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://blogs.oracle.com/takemura/entry/mysql_statement_based_replication%E3%81%A7%E3%81%AE%E5%AE%89%E5%85%A8%E3%81%AA%E9%96%A2%E6%95%B0
現場指向のレプリケーション詳説
Google Code Archive - Long-term storage for Google Code Project Hosting.
レプリケーション設定 - phpspot