フリーランスエンジニアをしているrevenue-hackです! 普段はGo言語でバックエンドを中心にやっています〜 ↓登壇したときの資料です! より図を入れて詳しく書いております! 今回はデータベースの特にRDBの仕組み(アーキテクチャ)についてざっくり理解して、なにかに役立てようぜ〜 というような内容になります。 ↓記事はこちらに移しました!↓
2020年10月19日 富士通株式会社 東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について 本日、株式会社東京証券取引所(以下、東京証券取引所)様より、さる10月1日に発生した東京証券取引所様の株式売買システム「arrowhead」の障害に関しての発表がありました。 東京証券取引所様、ならびに投資家の皆様、市場関係者をはじめ多くの皆様方に多大なるご迷惑をおかけいたしましたこと、あらためてお詫び申し上げます。 下記のとおり、本障害の根本原因および当社の品質保証体制の強化について、ご説明させていただきます。今後こうした事態を二度と起こさぬよう、再発防止に向け、全力を挙げてまいります。 記 東京証券取引所様の株式売買システム「arrowhead」障害の根本原因について (1)発生事象について 東京証券取引所様に共有ディスク装置として納入した当社ストレージ製
2020年10月1日、東京証券取引所はアローヘッドの機器故障によりシステム障害が発生し、終日売買を停止すると発表しました。故障した機器は交換が行われ、取引は翌日再開されています。ここでは関連する情報をまとめます。 機器故障起きるも縮退運用に失敗 障害概要図 アローヘッド内の共有ディスク装置1号機で機器故障が発生した。実際故障したのはサーバー上のメモリ周辺機器とされる。 1号機故障により両現用で稼働していた2号機のみのフェールオーバー(縮退運用)が行われるはずだったが何らかの問題により行われなかった。 共有ディスク装置を使用する相場配信、売買監視のシステムで障害が発生。 障害復旧時に発生する注文データ消失による市場混乱を避けるため当日終日の取引停止の措置を実施。(遮断) フェールオーバー失敗原因は設定ミス フェールオーバーに失敗した理由が特定できたとして10月5日に発表。 障害発生時のフェー
メモリのように書けて永続化される次世代ストレージデバイスNVDIMMの扱い方を解説します これは2019年10月19日に行われる予定だった カーネル/VM探検隊@北陸 5回目(台風の影響で中止) での発表資料です サンプルコード: https://github.com/Fadis/kernelvm…
DBのレイヤーを含むエンドツーエンドテストやDBに依存したコンポーネントの自動テストがたくさんあると、全てのテストが終わるまでに長い時間がかかるようになってしまうことがあります。DBのクエリ実行はネットワークIOやディスクIOなどを含んだ高コストな処理だからです。 Docker を少し工夫して使うと、お手軽にテスト中のDBのクエリ実行にかかる時間を削減できます。自動テストが完了するまでの待ち時間を短縮し、開発のフィードバックサイクルをより早く回せるようになります! MariaDB を用いたプロジェクトの実績では、DBアクセスを伴うテストケースが 153件 ありましたが、この方法によりそのテストスイートのローカル環境での実行時間を約 43% 削減できました(約 145.7s → 約 83.3s)。 どうやって? Docker で tmpfs を使います。 tmpfs tmpfs とは、ディス
iPad Pro (2024) review: So very nice, and so very expensive
MySQL 8.0で内部的に作成されるテンポラリテーブルが、HEAPストレージエンジンからTempTableストレージエンジンへと変更されたことは、皆さんもご存知だろう。このストレージエンジンはテンポラリテーブル専用として設計されたもので、実体を持ったテーブルとしての利用は想定していない。一応、internal_tmp_mem_storage_engineオプションを指定することで、従来のHEAPストレージエンジンも選択は可能であるが、個人的にはそれはお勧めしない。 TempTableストレージエンジンは、メモリとディスクの両方を自ら使い分ける。これは、従来型のテンポラリテーブルとは違う。HEAPストレージエンジンはインメモリ専用で、tmp_table_sizeあるいはmax_heap_table_sizeを超えるサイズが必要になると、ディスク上のテーブルへと自動的に変換が行われるという仕
Intel persistent memoryはデータの保持に電力を必要としない、不揮発性メモリの一種だ。データをメモリからストレージに保存する必要がなくなるなど、コンピュータのアーキテクチャを一変させる可能性を持つ。 現代のコンピュータは基本的にメインメモリとしてDRAMを利用しています。DRAMはアクセスが高速な一方、容量あたりの単価は高く、それゆえ大量にコンピュータに搭載することが難しく、またデータを保持し続けるのに電力を必要とします。 このDRAMの能力と性質を補完するため、一般に現代のコンピュータには二次記憶装置として大容量で安価かつ電力がなくてもデータを保持し続けられるハードディスクドライブなどのストレージを備えています。 こうした現代のコンピュータの構造を一変させようとインテルが5月16日に発表したのが、大容量かつ低価格、しかもデータの保持に電力を必要としない、同社とマイクロ
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く