あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡 (3) 困難篇 - asken テックブログ
こんにちは、インフラのテックリードをしている沼沢です。 この記事は、「あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡」の第3弾です。 第1弾、第2弾はこちらからお読みください。 あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡 (1) 絶望篇 あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡 (2) 希望篇 さて、前回はデータディクショナリ不整合が解消され、いよいよメンテナンス日を待つのみというところまで漕ぎ着けましたが、ここから(やらかし含む)様々な困難に直面していきます。 1st Take 2024年9月 中旬 レプリケーションを貼ったところまでは良かった。 良かったのですが、ここで私は大きなミスを犯します。 それは、「binlog 保持期間の設定を短くしすぎた」ことです。 も
RDS Proxyを用いたオンラインスイッチオーバーによるMySQLのアップグレードについて - freee Developers Hub
おはこんばんちは、DBREの橋本です。 今回は、Amazon RDS Proxy（以降RDS Proxyとよぶ）を用いたRDS for MySQLインスタンスおよびAurora MySQLクラスタのオンラインスイッチオーバーの手法について、ある程度社内での運用が確立してきましたので解説いたします。 従来のアップデート手法 AWS上でRDS for MySQLインスタンスやAurora MySQLクラスタ（以降これらをデータベースとしてまとめてよぶ）を運用している場合、それらのエンジンバージョンの更新を行ったり、OSバージョンの更新に伴う再起動を実施する必要があります。これらの更新を行う場合、以下のような方法が考えられます。 対象のデータベースに直接更新を適用する スナップショットを作成し、更新済みのデータベースとして復元する 更新済みの空のデータベースを新規作成し、そちらにデータを移行し、
MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズの Kubernetes 基盤を開発している Neco プロジェクトの ymmt です。 サイボウズ製品のほとんどはデータベースとして MySQL を採用しています。 現在 400 を越える MySQL のインスタンスを運用しており、これら全てを新しい Kubernetes 基盤に移行していく予定です。 Kubernetes 上でアプリケーションやミドルウェアの運用を自動化するソフトウェアのことをオペレーターと言います。 大量の MySQL インスタンスを Kubernetes 基盤に移行するにはオペレーターが必須であると考え、技術顧問の @yoku0825 さんの監修の下で MOCO というソフトウェアを開発しオープンソースライセンスで公開しました。 本記事では Kubernetes 上の MySQL オペレーターの状況と、開発した MOCO の機能を詳細に解説いたします。 M
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 したデータのリストア時のディスク
Redis の Slave (Replica) の Expire は 4.0 RC3 以降信用して良くなっている - その手の平は尻もつかめるさ
maedama.hatenablog.com trapezoid.hatenablog.com 上記のブログには今から6年ほど前の当時の情報が記されていますが，Redis 4.0 RC3 以降の Slave (replica) の Expire は信用して良くなっているようです． Redis の公式ドキュメント (Replication – Redis) を参照すると， However note that writable replicas before version 4.0 were incapable of expiring keys with a time to live set. This means that if you use EXPIRE or other commands that set a maximum TTL for a key, the key will le
InnoDBのテーブル断片化を解消させたいけどもマスターにそんなに容量が残っていない！ 時のテクニック
OPTIMIZE TABLE, ALTER TABLE .. Engine = InnoDB で空き領域が回収できることがわかっている SELECT table_schema, table_name, data_free FROM information_schema.tables WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') ORDER BY data_free DESC; とかで調べましょう 短時間（容量による）のメンテに入れられる オンラインの ALTER TABLE .. Engine = InnoDB では容量があふれそうである（または負荷的に耐えられないのでメンテに入れた方がマシ） MySQL 5.6.17とそれ以降はオンラインでできる（ただしフルテキ
セミナー行ってきた(MySQLのActive/Active型HA と 靴＆ファッション通販 ロコンド様の可用性への取り組み事例紹介) - 41から始めました
セミナー概要 2019-01-24（木）16:00 - 18:30 データベースのHAの話から、MySQL5.7から使用可能なマルチマスター型HAのMySQL InnoDB Clusterについての説明、および実運用での話をLOCONDO.jpの杉山さんから聞く。 資料については別途公開予定 イベント紹介 https://osslabo.doorkeeper.jp/events/85105 Amazonで約1時間のDB障害が発生し、100億円以上の機会損失が発生 備えあれば憂いなし！だが従来の冗長構成ではダウンタイムが発生？！ 技術者不足や人件費がかけられないという問題も MySQLユーザーに最適な答えとは 低コストで実現できる「MySQL InnoDB Cluster」解説 知ったこと(基本的にはMySQL InnoDB Clusterの話) 要件的なこと 構成可能台数は最大9(奇数にす
バージョン違いのPostgreSQLをロジカルレプリケーション - そーだいなるらくがき帳
PostgreSQL 10 から PostgreSQL 11へのロジカルレプリケーションを試した。 結論 簡単に出来る。 PostgreSQLのロジカルレプリケーションは元々バージョン違いを考慮してるのでPostgreSQL 10でのロジカルレプリケーションの設定と何も変わらない。 パブリッシャ（マスタ側）が10でサブスクレイバ(スレーブ側)が11を指定するだけ。 テーブル単位で出来るのでストリーミングレプリケーションとはそこも違う。 何が嬉しいか ロジカルレプリケーション自体のメリット・デメリットはここでは論議しない。 バージョン違いのPostgreSQLでレプリケーション出来るということはMySQLのようにレプリケーションでデータを複製しておき、フェイルオーバーさせることで停止時間を極小化してバージョンアップ出来るということ。 やり方 一番簡単なシンプルなやり方を記載する。 なお、前提
MySQLのレプリケーション手法の違い | Yakst
ソリューションエンジニアチームに所属する筆者が、今では様々な手法が存在するレプリケーション機能について、改めて特徴や注意点を解説しつつ、レプリケーションのよくある「誤解」に対してもお答えしています。 このブログ記事では、MySQL（および Percona Server）環境におけるレプリケーション手法に関して改めて考察を行いたいと思います。あわせて、時折見受けられるレプリケーションの間違った考え方についても考えてみます。 私がソリューションエンジニアとして働き始めてからというもの、沢山の情報が公開されているにも関わらず、レプリケーションに対する「誤解」や「不完全な理解」が無くならないことを日々感じていました。 そもそもレプリケーションとは何か？ レプリケーションは、1つのデータベースにデータを蓄積するだけでなく、別のデータベースにデータを複製し、転送することを保証してくれる機能です （複製
JDBCレイヤでDBのシャーディングを行うsharding-jdbcを試してみた - たけぞう瀕死ブログ
DBのデータ量が増えてきた場合の対策の1つとしてユーザIDなどをキーにデータベースを分割するシャーディングと呼ばれる手法があります。これをJDBCのレイヤで実現してしまうsharding-jdbcというライブラリを見つけました。 github.com sharding-jdbcは中国のdangdang（当当）というEC大手企業が開発したOSSで、SQLをパースし、SQLに含まれるシャードキーを抽出して接続先のデータベースや、参照するテーブルを切り替えてくれるというものです。 使ってみる まずはpom.xmlに以下の依存関係を追加します。 <dependency> <groupId>com.dangdang</groupId> <artifactId>sharding-jdbc-core</artifactId> <version>1.4.1</version> </dependency>
MySQL 5.7新機能解説：レプリケーション、セキュリティ編
今月の頭、詳解MySQL 5.7の出版記念第一弾として、MyNA（日本MySQLユーザ会）名義でイベントを行ったので、その際使用したスライドを紹介しておこう。今回紹介した新機能のカテゴリは2つ。レプリケーションとセキュリティである。レプリケーションはMySQLの運用と切っても切り離せないほど重要なものであり、そしてデータベースサーバーにとってセキュリティが重要であることは、言うまでもないだろう。 今回のバージョンでは、レプリケーションが大きく進化している。 まず、MySQL 5.7では、レプリケーションのトポロジの限界を打ち破った！！MySQL 5.6までのバージョンでは、スレーブはひとつのマスターしか持つことができないという制約があったのだが、それがなくなった。すなわち、スレーブが複数のマスターからデータを連続的に複製することができるようになったのである。それにより、これまで以上に様々な
UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた
Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス
分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
Redis:レプリケーション設定
Redis のレプリケーション設定についてメモ 公式ドキュメント http://redis.io/topics/replication Redis のレプリケーション マスターは複数のスレーブをもてる スレーブは別のスレーブの親になれる マスター/スレーブのレプリケート処理はノンブロッキング スレーブは writable (2.6 からは slave-read-only 設定が追加され、デフォルトは read-only) スレーブの用意 スレーブ用 redis サーバーを起動する。同じサーバ内に起動するのであれば、ポートを変更する必要がある。 redis.conf の port を修正すること。 スレーブ設定方法 confファイルでの設定 redis.conf にマスターの情報を記述する slaveof <masterip> <masterport> ex) slaveof 192.168
RedisをSentinel構成で運用しているときのSlaveノードの切り離し - 元RX-7乗りの適当な日々
RedisでSentinelを使った構成で組んでいると、レプリケーションの制御をSentinelがよしなにやってくれるんだけど、あるSlaveノードを永久に切り離したいってなった時に、どうやるかって話。使っているバージョンは2.8系(下記のテストで利用したのは2.8.7。) 結局、ベストなやり方がわからないのだけど、以下のような感じで実施している。(いいやり方があれば教えてください。) 問題 通常、Redisでレプリケーションの解除は、 $ redis-cli slaveof no one"SLAVEOF no one"コマンドを使うと良いのだけど、これだけだとSentinelが保持しているスレーブノードの情報は保たれたままなので、しばらくするとSentinel君が、レプリケーションが切れていることを検知して自動で再開してくれるような挙動になる。 なので、Sentinelからスレーブノード
Redis + Sentinel で自動フェイルオーバ in Amazon VPC を試してみた - matetsuだもんで
お久しぶりです。 最後にブログを更新したのがInternal ELBが登場して勢いで書いた6月11日。。。更新してなさすぎですね。 そこで今回試してみたのは、Redis + Sentinelの自動フェイルオーバをAWS VPC環境で実現するというものです。 元々は「 RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店 」を参考にして構築しようと考えていたのですが、VPC(というかAWS)の環境ではbroadcastやmulticastが使用できないので、VRRPが使えず断念。そこで少し途方にくれつつ考えたのが、Sentinelを使う方法。 Redisについては特に説明は必要ないと思いますので、Sentinelについて簡単に。 監視: masterやslaveが期待通り動いているかどうかを定期的に監視 通知: 指定したログレベルのものが発生した時に、管理者や
RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店
master slave 構成を取っている Redis で、master が落ちた場合に slave を昇格させてフェイルオーバーしたいという要件がありまして、Keepalived と組み合わせて構成してみました。Redis の運用経験がないのでご意見などいただければありがたいです。 Scientific Linux 6.2 keepalived-1.2.2-3 redis-2.4.10 前提 Redis のレプリケーションではマルチマスター構成を取ることができない Redis の slave は起動時に master に接続し、全データを取得してコピーを取る その後は順次 master で更新されたデータをコピーする redis-cli で slaveof コマンドを実行することで、動的に master, slave を切り替えることが可能 このような作りになっているため、2ホスト間で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DB tech showcase_tokyo2018_LOCONDO
Redis is easy. Redis is trivial. Redis is HARD!
How fast is Redis? – Redis