You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
最近、とあるサービスの本番環境にMySQL5.6を導入していっています。社内だけの環境も含めて5システムに導入しました。 5.5からのアップデートや最初から5.6というものもあります。 今回、導入で変わった点いろいろありますが、メモ程度にまとめておきます。 間違いなどありましたら指摘していただけるとありがたいです。 Replicationエラー時 今までは、replicationのエラーが起こった場合は SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; とかでダメなクエリを確認しつつSKIP出来ればしていましたが、5.6でGTIDモードONの場合、これが使えなくなりました。 GTID便利なんですが、この点少し不便です。 以下のように直します。 まず、slaveでmaster server UUIDと最新のGTID、Retrieved_Gtid_Setを確認します
さくらインターネット研究所さんの「MariaDB Galera Clusterを試す」という記事を読んで居ても立ってもいられなくなり、さっそく AWS で構築してみました。 上記の記事によれば 簡単にまとめると次のようになります。 Galera Replicationが複数のRDBMをレプリケーションするwsrep APIを提供し、同期をとります 完全同期型であるため、すべてのノードがアクティブかつマスターとなります クラスターノードのどれに対してもリード/ライトが可能です ノードの追加/削除は自動で行えます クライアント接続は通常のMySQLとなんら変わりなく使えます via. MariaDB Galera Clusterを試す (1) « さくらインターネット研究所 おー!スレーブ/マスター形式のレプリケーションよりも、断然使いやすそうやんか! ってわけで AWS の ELB 配下に複
Cloud Management Platform Implement an industry-leading cloud management solution for all cloud use Among the industry’s leading cloud management platform tools, Flexera’s comprehensive Cloud Management Platform (CMP) provides a rich set of capabilities for discovery, template-based provisioning, orchestration and automation; operational monitoring and management; governance; and cost optimization
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台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く