Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog
SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯（ステージング環境を後から立てたり！）から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
Goで作るDBレプリケーションツール
gopli - DB replication tool to synchronize data with multi environments written in Golang. ツールの名前はgopli (go replication)で、意図どおりの名前ですね。 これは何tomlで書いた、ssh/db接続用の設定ファイルを元に、特定の環境間でデータを同期させるツールです。今の所MySQLのみ対応で、postgresqlに対応しろと言われたものの、なかなか手が回っていない状況です。 使い方は簡単で、 まず以下のように、 sshでのサーバーへの接続と、MySQLへの接続設定をtomlで書きます。 [database] [database.local] host = "localhost" management_system = "mysql" name = "app_developmen
MySQL 5.7新機能解説：レプリケーション、セキュリティ編
今月の頭、詳解MySQL 5.7の出版記念第一弾として、MyNA（日本MySQLユーザ会）名義でイベントを行ったので、その際使用したスライドを紹介しておこう。今回紹介した新機能のカテゴリは2つ。レプリケーションとセキュリティである。レプリケーションはMySQLの運用と切っても切り離せないほど重要なものであり、そしてデータベースサーバーにとってセキュリティが重要であることは、言うまでもないだろう。 今回のバージョンでは、レプリケーションが大きく進化している。 まず、MySQL 5.7では、レプリケーションのトポロジの限界を打ち破った！！MySQL 5.6までのバージョンでは、スレーブはひとつのマスターしか持つことができないという制約があったのだが、それがなくなった。すなわち、スレーブが複数のマスターからデータを連続的に複製することができるようになったのである。それにより、これまで以上に様々な
mikasafabric for MySQLクイックスタート | GMOメディア エンジニアブログ
ぬいぐるみが好きな方のDBAです。 mikasafabric for MySQLをオープンソースライセンスで公開しました で紹介した mikasafabric for MySQL（以下mikasafabric）のチュートリアルです。 決して社内向けのドキュメントを書くのが面倒になったからブログに書いている訳ではありません。なお、特に明記しない場合はmikasafabricとMySQL Fabricで手順は変わりませんので、オリジナルのMySQL Fabricのクイックスタートとしてもご利用いただけるようになっております。一粒で二度美味しい。 まず、mikasafabricはMySQL Fabricのクローンなので同じコンポーネントが必要になります。 バッキングストアと呼ばれるmysqldmikasafabricデーモン(mysqlfabric)mikasafabricなのにプロセス名がmy
mikasafabric for MySQLをオープンソースライセンスで公開しました | GMOメディア エンジニアブログ
あまりにもつらかったので、おとなしくフォークして自前でパッチを当てることにしました。フォークするついでに名前を変えたのが mikasafabric for MySQL （みかさファブリック フォー マイエスキューエル）になります。 期待通りに使えるMySQL Fabric を目指した結果なので、まあまあ期待通りに動きます（ただし、MySQL Routerとの組み合わせしかサポートしていません。他のコネクターは動くかも知れないし動かないかも知れない。一部、APIの戻りにも手を入れているので） 名前を変えた理由- MySQLは商標なのでフォークとはいえMySQL Fabricは微妙（MySQL xxxはダメで、xxx for MySQLならOK） - mikasafabric for MySQL は MySQL Fabric 1.5.6 をベースにしているので、リポジトリー分けるまでは1.5.
FacebookのSimon Martin氏への準同期レプリケーションについてのインタビュー(The Percona Performance Blogより) | Yakst
FacebookのSimon Martin氏への準同期レプリケーションについてのインタビュー(The Percona Performance Blogより) 出典について この記事はThe Percona Performance Blog内のTom Diederich氏によるFacebook’s Simon Martin on semi-synchronous replication(2015/9/4)を翻訳したものです。 Facebookには月間14.9億のアクティブユーザーがおり、世界の最大のMySQLユーザーの1つである。FacebookのMySQLインフラチームのプロダクションエンジニアであるSimon Martinは、スペアのない2台のサーバーから始まって、世界で最大の規模の1つになるまで、キャリアの大部分でMySQLに取組んできた。 SimonはFacebookが取組んできた、
レプリケーションのパスワードはmaster.infoに書かれている - There's an echo in my head
MySQLでレプリケーションする際にCHANGE MASTER TOで設定したパスワードは、データディレクトリ下のmaster.infoファイルに書かれている。
MySQL入門 レプリケーション編 - Qiita
#経緯 とある勉強会の内容の復習＆整理 #タイトル インストール・アーキテクチャ基礎編 レプリケーション編 ←今回はこちら バックアップ編 チューニング基礎編 #レプリケーション編 アジェンダ レプリケーションとは レプリケーションの仕組み レプリケーションの種類 レプリケーションの設定方法 バイナリログの管理方法 その他の考慮事項 参考情報 #1. レプリケーションとは ##1.1. 基礎知識 データの複製（レプリカ）を別のサーバにモテる機能 MySQLの標準機能で、多数のWebサイト等で利用されている － シンプルな設定で利用可能 － マスター → スレーブ構成 ##1.2. マスタースレーブ構成 サーバはマスター、スレーブまたは両方になれる マスターサーバ － データを変更 － 変更内容をスレーブに転送 － マスターは複数のスレーブを持てる スレーブサーバ － マスターでの変更内容を
MongoDBとElasticsearchを同期させる - Qiita
それRiverでできるじゃん はい、そうです 素直にRiver Plugin使えばいいのですが River用にレプリケーションを組まなきゃない Elasticsearch本体のバージョンとプラグインのバージョン違いが思わぬところで地雷になる その他の事情 などの理由でRiverを使わない場合はどうすんべという話 Mongooseにはmiddlewareという機能があり、他のRDBMSのTrigger機能のように各種のメソッドコールに処理を差し込めるので、これを使うことにします 実装 予めElasticsearch側のインデックスを作っておく そしてMongooseとElasticsearchを結ぶようなモデルを作る 個人的にはapp.jsの下にlib/model.jsだったりlib/model/db名.jsとか作るのが好みです module.exports = function(){ va
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
Mongoクエリー・ベース・レプリケーション - 中年engineerの独り言 - crumbjp
レプリカセット間レプリケーション MongoDBではレプリカセットを跨いでデータを同期する手段が無い。 そもそもレプリカセット自体が冗長構成を目的としているので設計に組み込まれていないのだろう。 しかし現実は Staging環境や、PV系／集計系の分離など、用途はある。 今は、レプリカセットのslaveを１台切り離してそこで何かするしかない。 フレッシュデータじゃないし運用も面倒。 monmo-repl https://github.com/monmo/monmo-repl なければ作れば良いので作った。 oplogベースの同期を行う。-s で指定したレプリカセットのPRIMARYのoplogを読み、-d で指定したレプリカセットに反映していく。 PRIMARYダウン時の挙動など、まだ未テストの部分は多いが 『とりあえず動く』 程度の完成度。 例 ReplicaSet1 =sync=> R
MySQL User Forum - MySQL Replication & MySQL Fabric (Japanese)
MySQL Fabric と Replication の機能を解説します。 2014年4月25日に開催したMySQL User Forum のセッションの１つです。MySQL User Forum は、MySQL 5.7を含む最新開発・技術動向、パフォーマンスの強化ポイント、MySQL製品紹介、最新版のMySQL Workbenchデモなど、MySQL の最新の技術情報をお届けしました。 Subscribe to the MySQL Youtube channel and watch more tutorials and presentations: http://www.youtube.com/mysqlchannel Like the MySQL facebook page to receive latest updates on product releases, technical
MariaDB 10.0 GA記念 並列レプリケーションって何？ - interdb’s blog
2014年3月末にMariaDB 10.0.10 GAがリリースされて、並列レプリケーション(Parallel replication)が目玉の１つっぽく書かれているので、簡単に解説。(2014.12.3追記：以下の書籍にも記述した。) 並列レプリケーションとはスレーブ側の機能で、従来はSQLスレッド１つで処理していたrelayログの再生を、複数のスレッドで並列に処理しようというもの。 MySQLにもパラレルworkerという機能があるが、MariaDBのそれとは並列化の粒度が全く異なる。(注：MySQL5.7でMariaDBと同レベルの機能が実装された。) MariaDBのマスタがコミットしてバイナリログを書く際に、並列実行できるかどうかをバイナリログに書き込んでいる。スレーブはそれに応じて、並列に実行できるSQLは並列に実行する。 具体例をみてみよう。 マスタでbinlog_commi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - timakin/gopli: DB replication tool to synchronize data with multi environments written in Golang.
MySQL group replication: installation with Docker
Improving the design of MySQL replication
Ansibleで始めるpostgre sqlの冗長化
