先日は、MySQLユーザ会会 2020年7月に参加しました。 今回はWebや雑誌で連載の著者の方々が、執筆に至った経緯や、執筆時に心がけていることを語る回でした。 @kk2170 さんが「過去の自分に向けて書く」とおっしゃっていたのが、（そういう視点は自分の中になかったので）すごく響きました。 mysql.connpass.com -- 一刻も早くレプリケーション遅延を取り戻したい！そんな場合に使える小技を紹介します。 レプリケーションを止めずに有効化・無効化できるのみを取り上げています。 元に戻すのにレプリケーションを止める必要性のある方法だと、またそこでレプリケーション遅延が発生しますからね… CPU の governor を performance に変更する LinuxにはCPUクロックの調整機能があり、CPU governor が ondemand 設定の場合、負荷に応じて、CP
今回は、MySQL/MariaDB GTID レプリケーションの詳細を説明します。これは、Transactdによるレプリケーションセットアップ（修復）ツールを構築する際に調べたものです。 主に従来のバイナリログとポジションを使ったレプリケーションとGTIDによるレプリケーションの違いについて説明します。ある程度従来のレプリケーションのセットアップなどを理解していることを前提にしています。 Index なぜGTIDが必要なのか GTIDが活きるシナリオ GTIDによるポジションの解決 具体的なGTID GTIDを使うための設定 MariaDBでGTIDを使う 2つのGTIDポジションモード 新規セットアップ スレーブで、マスターを新マスターに切り替える ダウンしたマスターをスレーブ群に加える SQLスレッドのエラーを修復する MySQLでGTIDを使う GTIDセット GTIDセットの表現方
・使用環境： Debian 2.6 MySQL 5.1 CASE: とある案件でMySQLのレプリケーションを作ることになった。 MySQL公式サイトの レプリケーションの設定 の手順通りに進めていったのだが、最後らへんの #MySQL上のコマンド mysql > show slave status;を実行した時に、 #抜粋 Last_IO_Error : error connecting to master 'repl@[マスタDBが置いてあるIPアドレス]:3306' - retry-time: 60 retries: 86400が表示されていて、接続エラーを起こしているという。 スレーブ側の設定が悪かったのかと思って、考えつく限りの方法を(最初から設定し直すなど)試したが何も変わらず。 職場の先輩からのアドバイスで、スレーブ側サーバのコマンドライン上で $ telnet [マスタDB
MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を 発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。 さらに、RESET SLAVE ALL;というクエリもサポートされたようです。 どういう事なのでしょう？ 調べてみました。 ドキュメントにさらっと何か書いてある In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. Thi
1. はじめに この記事はMySQL Casual Advent Calendar 2015の22日目のエントリです。 先日、MySQL Casual Talksという勉強会で登壇してきました。その時の内容をまとめておきたいと思います。 MySQLデータベースサーバに障害が起きた時、サービスを続けるには幾つかの方法があります。障害発生時にSlaveサーバーを手作業でMasterに昇格させる方法、MySQL Utilitiesに含まれるmysqlfailoverというユーティリティーを利用する方法などです。 今回、Keepalivedというソフトウェアと、MySQLの双方向レプリケーションを使って、ほぼ無停止でフェイルオーバーする構成を試してみたので、それについてまとめておきたいと思います。 2. システム構成 db1、db2という二つのサーバで、それぞれmysqldとkeepalivedを
Original Streaming Replication搭載のPostgreSQL9.0リリースが近づき、MySQLとのレプリケーション比較が今後ますます盛んになると思われるので、PostgreSQLユーザ向けにMySQLの説明を行う。 参考->MySQLユーザのためのPostgreSQL:WALログとレプリケーション講座 なお、なぜ最初に延々とバイナリログを説明するかといえば、MySQLのレプリケーションでマスタからスレーブに送るのは、バイナリログのデータだからである。 [レベル:1] MySQLのバイナリログ MySQLにはWALログに直接対応するものはない。理由はMySQLがマルチストレージエンジンだからである。 マルチストレージエンジンについては後述するのでここでは簡単に説明すると、 MySQLはトランザクション機能ありのInnoDB型というテーブルや、トランザクション機能なし
RESET SLAVEでリセットされる範囲
RESET SLAVEだけの場合、master_log_name, master_log_pos, ssl_verify_server_cert, heartbeat_periodのクリア。 RESET SLAVE ALLの場合、↑に加えてhost[0] = 0; user[0] = 0; password[0] = 0; される。 gtid周りの情報はhiroi10さんの gtidを使用した環境でのmysqldump が詳しい。 【2013/05/20 12:07】 MASTER_SSL_*は？ ⇒「メモリ上からは」クリアされない。 RESET SLAVEだけでもMySQL再起動したら消える気がするけど？ ⇒RESET SLAVEは「メモリ上の」↑の情報と、master.infoファイルを消す。 再起動するとメモリ上の情報は全て吹っ飛ぶ && master.infoから読もうにもmast
Klikbet77 Best – Platform Resmi Fitur Lengkap & Update Game Berhadiah Terbaru Klikbet77 Best menyediakan platform resmi dengan fitur lengkap, update game berhadiah terbaru, serta performa yang stabil. Cocok bagi pemain yang mencari kenyamanan, informasi akurat, dan pengalaman bermain yang optimal. Klikbet77 Be kind to each other. Hours: Wednesday-Thursday: 3-10pm Friday-Saturday: 12-10pm Sunday: 1
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
悩んだり調べたりした過程も書いているので、記事が長くなってしまった。まとめるのが下手だ。早くスレーブサーバでもバイナリログを有効にする方法が知りたい人は読み飛ばしてください。 MySQLでレプリケーションを組みました。レプリケーションサーバでは、こちらの都合でサーバを停止することができるので、停止して安全にmysqldumpによるバックアップをしています。 その時点でのフルバックアップはmysqldumpでとれるのですが、差分バックアップに使うにはバイナリログも同時にバックアップする必要があります。バイナリログがスレーブサーバでも有効になっていれば、バイナリログファイルが作成されるので、特にそれ以上のバックアップは必要ないと思っていました。 マスターサーバとスレーブサーバの設定ファイルは、基本的に同じ設定だと思います。スレーブサーバで参照を分散させている場合は、メモリ割り当てなどは違う部分
MySQLでレプリケーションする際にCHANGE MASTER TOで設定したパスワードは、データディレクトリ下のmaster.infoファイルに書かれている。
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
昨夜、Webアプリに対するリクエスト数が急激に増大し、MySQLのスレーブに対するレプリケーションのタイムラグがみるみる増加し、アプリケーションロジック上のエラーが頻発するようになってしまった。 一昨日のピークが秒間300リクエストちょい、昨日が800超え。。。おそるべし、ソーシャルアプリ。 cacti で見ていたタイムラグの単位が、てっきりミリ秒だと思ってたら、実は秒だったことが発覚して、青ざめた。 遅延が2秒になっちゃったよ、やべーよ、と話していたら、実は2,000秒だった罠。。。orz オワットル。ひさびさにシビれた。。。 実践ハイパフォーマンスMySQLに助けを乞うと、「 8.7.14 レプリケーションの過度の遅延」というまさにぴったりの項目があり、とにかくスレーブに余計な仕事をさせるな、とのお達しが。ディスクのIOWaitが結構あったので、ディスクへのIOを減らす目的で、本で紹介
MySQLで、マスタ系を動かしたまま、スレーブの更新を一時的に止めたいという状況はよくあります。スレーブ群の中から一台だけサービスアウトし、STOP SLAVE;してテーブル変更やリペアテーブルしてからSTART SLAVE;するというやつです。 このSTOP SLAVE;ですが、MySQLプロセスを再起動すると勝手にSLAVEが再開してしまいます。ですので、テーブル変更時にうっかり（ディスク増強などのために）MySQLを再起動するといつの間にかレプリケーションが始まってウワーッとなります。悲しいですね。 my.confにこのようなレプリケーションの自動開始の抑制オプションがないか探してみましたが、ないようです。skip-networkingを有効にしておけばスタンドアローン化するかと思いましたが、これは「TCPをリッスンしない」オプションなので、リッスン側のマスターでレプリケーションを抑
“MySQL Casual Advent Calendar 2011” 7 日目を担当させていただく、hatak (@hisashi) です。 普段はモバイルゲームのインフラをメインにみているのですが、今回はそんな業務で経験したことを基に記事を書かせていただきます。 カジュアルすぎる内容かもしれませんが、お付き合いいただければと思います。 MySQL のレプリケーション MySQL のレプリケーションは、安定稼働やバックアップ、負荷分散などの目的に利用できる優れた機能です。 bin-log (バイナリログ) を利用して Master サーバから Slave サーバに更新を伝播させ、データの複製を行います。Slave サーバでは、2 つのスレッドが動作しています。 IO_THREAD – Master から送られてきたデータを受け取り、relay-log (リレーログ) として書き出す SQ
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
稼働中のMySQLを無停止でレプリケーション環境を構築する 個人メモです。稼働中のサービスを停止できないけど、スレーブを増やしたい（増殖したい）なんて場合に使える技になります。 マスターのバックアップ まず、スレーブ側のホストでマスターのスキーマ（例では、schema1 schema2のバックアップをとります。この際に、--master-data と --single-transaction は必須です。 --master-data を指定しますと、master側のバイナリログファイルとポジションを取得することができます。 --single-transaction を指定しますと、innodbの場合は、マスターサーバ側のデータベースをロックせずに、dumpすることが可能です
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
