ご注意 本ドキュメントは 2019/12 時点の状況での検証結果をまとめています。 コメントに頂きましたが 2020/9 に CloudSQL がレプリ元をFQDNで指定可能となった (ref) ようで、Aurora -> CloudSQL へ MySQL レプリケーションができるようになった可能性がありますのでご注意ください。 はじめに ZOZOテクノロジーズでSREチームに所属している@hkameです 普段はZOZOTOWNのオンプレ基盤を運用しております ZOZOTOWNはレガシーなシステムから徐々にパブリッククラウドへのリプレイスを実施していまして そのプロジェクトに関わりながら、日々クラウドやk8s・CICDのスキルを吸収している人です マルチクラウドでサービスを構築するための検証として Aurora->CloudSQLの2サービスのみで、MySQLのレプリケーションができるか
こんにちは。コネクト支援チームの風穴(かざあな)です。 この度サイボウズでは、GMOメディア株式会社とコンサルティング業務委託契約を締結させていただき、MySQLエキスパートのyoku0825さんに、いろいろと相談に乗って頂けることになりました。 MySQLについて検索したことがあるエンジニアなら、yoku0825さんのブログ「日々の覚書」のお世話になったことがない人はいないでしょう。それぐらいポピュラーなブログで、日本語で読めるMySQLの技術情報を長年発信し続けているのがyoku0825さんです。 yoku0825さん ということで、Garoonプログラマの杉山くんと一緒に、yoku0825さんにお話を伺ってみました。 yoku0825さんのお仕事 ──(風穴):普段、どんなお仕事をされてるのですか? yoku0825さん(以下、敬称略):GMOメディアという、BtoC向けのWebサー
This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their core components. It then provides a table comparing 8 popular open source messaging platforms: Apache Kafka, ActiveMQ, RabbitMQ, NATS, NSQ, Redis, ZeroMQ, and Nanomsg. The document discusses using Apache Kafka for streaming and integration with Google Pub/Sub, Dataflow, and BigQuery
マジセミドライブ ウェビナー関連のニュースやITサービス&ツールの最新情報を随時配信します。 TOP 記事一覧 【OSS情報アーカイブ】MySQL MHA OSS情報 2020.01.01 【OSS情報アーカイブ】MySQL MHA ※当記事に記載されている情報は、古くなっている場合があります。オフィシャルサイトで最新情報をご確認ください。 コンテンツ 「MySQL MHA」とは 基本情報 概要 MySQL MHA(マイエスキューエル エムエイチエー)とは、MySQLマスタ障害発生時に、MySQLマスタの自動フェイルオーバーを行い高可用性を実現するオープンソースツールです。 基本説明 「MySQL MHA」は、「Master High Availability Manager and tools for MySQL」の略称です。 Perlで実装されており、マスタとスレーブで構成されるMyS
2. me • Masahiro Nagano • @kazeburo • NHN Japan • Operations Engineer Site Reliability 運用系小姑 Perl Monger 2013年3月8日金曜日 3. MHA for MySQLとは • 元DeNA・現facebookの松信さんによる MySQLのmaster冗長化ツール • Master High Availability の略 • MySQLサーバを監視してのフェイルオーバー とオンラインでのマスター切り替えをサポート • Proxy型ではないのでSPOFにならない • サーバの切り替えは別スクリプトを起動 2013年3月8日金曜日
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです! 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
TL;DR information_schema.innodb_buffer_page は重い ib_buffer_pool にはテーブルスペースIDが記録されるので、それを使ってほげほげする こんな感じ? mysql> SET GLOBAL innodb_buffer_pool_dump_now = 1; mysql> SELECT space, name FROM information_schema.innodb_sys_tablespaces INTO OUTFILE '/tmp/space.txt'; $ awk -F, '{print $1}' /var/lib/mysql/ib_buffer_pool | sort | join - <(sort /tmp/space.txt) | uniq -c | sort -n -r -k 1 | head 54570 50 hogeh
結論としてはできない。正確にはレプリケーションの設定自体はできるがデータが適切に複製されないので設定を変える必要がある。 これはMySQL5.6 -> Aurora(MySQL5.6互換)移行の際、レプリケーションを組んだが、時刻周りで上手くいかなかった問題と解決の記録。 そして、はてなエンジニア Advent Calendar 2018の2日目の記事です。 qiita.com 前提 件の移行の際のmaster以下のような設定だった。 mysql> show variables like '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | JST | | time_zone | SYSTEM | +-
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった:データベースの不整合解消に時間 GitHubは2018年10月30日(米国時間)、2018年10月21日16時頃(米国太平洋時)から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータ管理データベースの不整合を引き起こし、復旧に時間を要したという。 GitHubは2018年10月30日(米国時間)、2018年10月21日16時頃(米国太平洋時)から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基本的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く