GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
パブリックブロックチェーン上の価値をリアルタイムで安全にやりとりできるプロトタイプを開発
株式会社Nayuta(本社：福岡市中央区、代表取締役：栗元憲一)は、パブリックブロックチェーン上の価値をリアルタイムで安全にやりとりできるプロトタイプを開発しました。 仮想通貨技術で2nd Layerと呼ばれる、双方向Micropayment channel技術(*1)とHTLCs(Hashed Timelock contracts)技術(*2)を組み合わせ、Testnet上のビットコイン(*3)をブロックチェーンのブロックタイム時間待つことなく安全にやりとりを行います。 ClientソフトウェアとHubソフトウェアを独自実装し、Hubにデポジットしている任意の二者のClient間でビットコインの送受金を行います。この際、Hubはビットコインを横取りすることが不可能であり、また受領者はビットコインのブロックタイム時間10分を待たずに受金したと安全に判断できます。 HUBを通したClient
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
