概要 この記事ではTiDBv6.1でのPoint In Time Recovery(PITR)について私なりの方法を紹介します。 運用中にめったに行うことはないですが、PITR (wikipedia)がいつでもできることは運用上重要ですよね。 しかし、残念なことに2022/07/06現在、TiDB公式ドキュメントにPITRの説明はないようです。まずはこのことを確認し、その後、TiDB Binlogを利用してユーザデータをPITRする方法を紹介します。 ユーザデータと書いたのはTiDB Binlogという更新差分を取得する仕組みがDCLによる変更内容を補足しないためです。つまり、CREATE USER文やGRANT文は厳密にPITRすることができません。 (DCLによって更新されるデータを"ACLデータ"、それ以外のデータを"ユーザデータ"とします) 以前の記事に引き続き、GCP上で動作確認

はじめに 最近TiDB導入のための検証にアサインされて、TiDBを調べています。 MySQL互換のデータベースということでTiDBを試してみるなら、無料トライアルも用意されているフルマネージドのTiDB Cloudを利用してみると良さそうです。 しかし、実際に本番環境で利用したり、TiDBを含めたシステムを運用するためには分散システムであるTiDBの各コンポーネントの理解が必要で、そのためには自分でコンポーネントを建てたり落としたりしながら徐々にアーキテクチャを理解するのが良いでしょう。 (*TiDBにはTiDB serverをはじめPlacement Driver(PD), TiKV, TiFlashなど様々なプロセスを必要としますが、ここではこれらを"コンポーネント"と呼んでいます。TiUPのサブコマンドも"コンポーネント"なのでややこしいですが、ドキュメントのTiDB Archite

Support this Site Become a Six Colors member to read exclusive posts, get our weekly podcast, join our community, and more! By Dan Moren November 19, 2020 6:35 AM PT Last updated August 18, 2023 Update: As of macOS Sonoma, there’s a new and improved method for enabling this feature that’s designed to survive a system update. My new MacBook Air is proving to be all that I’d hoped, and it’s not just

こんにちは、 id:alpicola です。今年4月に新卒入社してアプリケーションエンジニアとして働いています。 ウェブアプリケーションはその性質上、データベースに対して同時に大量の問い合わせを行います。そうした中でデータベースが個々の問い合わせを処理していくときに起こっていることは何か、どういう順序で処理が行われるのか、というのは興味深い話題かと思います。例えばデータベースに対して行った更新処理の結果が、更新を行ったクライアント以外のクライアントからも「見える」ようになるのはいつでしょうか。入社間もない頃、先輩エンジニア達にそうした疑問をぶつけてみたところ、「トランザクション分離レベル」というキーワードと、この分野の古典的な論文 A Critique of ANSI SQL Isolation Levels を教えてもらい、輪読会を社内で開催しました。この記事ではこの輪読会の模様をレポー

※こちらは先日実施された DeNA インフラエンジニア / SRE MEETUP で話した内容を Blog 記事化したものです！ こんにちは！IT基盤部の熊谷です。IT基盤部にて大規模ゲームのインフラを見ている 新卒２年目のインフラエンジニアです。この記事では “DeNA でのデータベース運用とそのツラミ” と、“TiDB導入への検証・検討” をご紹介させていただきます。 データベースの最適解 DeNA のデータベース構成は最適解を求めて改良を積み重ねてきました。最初期の構成、(便宜上、第１世代と呼びます) では VM Instance 上に MySQL を構築し管理する MySQL on EC2 構成。続く第２世代では、マネージドサービスを駆使した Aurora MySQL 構成。この２世代の中で生じた “ツラミ” を解消する次の世代、言わば 第３世代に該当する新しいデータベース構成を現

kubenertesを使っていてハマったのでメモ。 kubectl apply -f でエラー kubectl apply が便利なので何でもかんでもこれでデプロイをしていたが、とあるリソースファイルをデプロイしようとしたところ以下のようなエラーが $ kubectl apply -f dashboard.yaml The ConfigMap "dashboard" is invalid: metadata.annotations: Too long: must have at most 262144 characters 原因 kubectl apply ではロールバックなどのために更新前のリソースファイルをmetadata.annotationsに自動的に格納してくれている。metadata.annotationsの容量制限は256KBであるため、本来容量上限が1MBのConfigMa

「Command＋スペース」で入力モードを切り替える人は少なくないと思いますが、2016年9月登場のmacOSの最新バージョン「macOS Sierra」から「Command＋スペース」の挙動が変わり、画面中央に表示されるダイアログに制御が取られやすくなりました。 結果として入力モード変更が不発に終わることが増え、非常にストレスが溜まるようになりました。 これは設定で以前のような挙動に戻すことができます。 「システム環境設定＞キーボード＞ショートカット＞入力ソース」の割り当てを上下逆に。 具体的には、設定項目を選択して青く反転させた後で、キーボードショートカットの部分をクリック。 「⌘スペース」の方ではCommand＋Option＋スペースを押下。 「⌘⌥スペース」の方ではCommand＋スペースを押下。 これで割り当てを逆にします。 以降、「Command＋スペース」を押すと「入力メニュ

All of Percona’s open-source software products, in one place, to download as much or as little as you need.

以前、MySQL8.0 で MySQL InnoDB Cluster を構築する の記事で MySQL 8.0.4 RC版を使った構築方法をご紹介しましたが、あれからバージョンも進み、新機能がいくつも追加され、 MySQL InnoDB Cluster の構築方法も5.7、8.0RC版を経て以前よりも簡単に自由度も高くなりました。 今回の記事では改めて MySQL 8.0.13 を使ったセットアップ方法をご紹介したいと思います。 MySQL InnoDB Cluster とは？ MySQL InnoDB Cluster は下記のコンポーネントをまとめた名称で、それ自体が1つの製品ではありません。 コンポーネント同士が強く結びついて動作させることが前提のため、サードパーティ製品を導入する際に組み合わせにより発生するトラブルに悩まされることもなく、汎用的なツールにありがちな複雑な設定やセットア

epoll を使った prefork 型アプリケーションサーバーにおける Thundering herd 対策の決定版として注目されていた EPOLLEXCLUSIVE が、 3/13 にリリースされた Linux 4.5 で導入されました。 昨年 SO_REUSEPORT というソケットオプションが登場して、 Thundering herd 対策として話題になったものの、ワーカーごとに listen キューが作られるため graceful restart するときに listen キューに入ってるリクエストを取りこぼす可能性があり利用するのが難しい状況でした。 参考: epoll の thundering herd 問題について解説しているサイト http://tech.geniee.co.jp/entry/so_reuseport http://uwsgi-docs.readthedo

epoll | RubyGems.org | your community gem host ksss/epoll · GitHub epollはnginxやnode(libuv)などでも使われている、大量のファイルディスクリプタを効率よく監視するためのAPIのことです。 イベントドリブンI/O epoll APIはLinuxでのみ(たぶん)動作し、Mac等のBSDでは似たAPIとしてkqueueがあります。 例えばepollを軸にサーバーを作るなら、serverが作った各クライアント間とのI/Oをできるだけ待ちをなくして読み書きできるときに実行する事が可能です。並行で低リソースに処理できるので、大量のリクエストを同時に処理することが期待されます。 epollではレベルトリガ通知(今なら大丈夫通知！)、エッジトリガ通知(前から変わったよ通知！)のどちらにも対応し、いわゆるイベントド

Google Researchにて「Large-scale Incremental Processing Using Distributed Transactions and Notifications」という論文が公開されました。GoogleはこれまでMapReduceにて大規模な処理を扱っていましたが、常にデータ全体に対して行わなければならず、小さな更新をたくさん行うような処理には向いていません。これに対し、Web検索エンジンのようにクローラがWebページを取得するたびに逐次的に処理を行い、短い間隔で検索インデックスの更新を可能にしたシステム「Percolator」を構築しました。論文ではPercolatorの概要やアーキテクチャ、導入による効果検証について書かれています。 Percolatorの特徴は、ペタバイト級のリポジトリに対してランダムアクセスが可能な点です。また、利用者側がリ