システム移行メンテナンスにおける一部時間帯に更新されたデータが消失した原因のご報告 - Mackerel お知らせ #mackerelio
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
PostgreSQLには、用途や環境に応じて様々な構成を組み、最適なパフォーマンスで動作させられるよう、設定ファイルpostgresql.confに多くのパラメーターが存在します。そのパラメーターを正しく設定し調整を行うためには、PostgreSQLのアーキテクチャーを理解する必要があります。ここでは、押さえておきたい、PostgreSQLの基本的なアーキテクチャーについて説明します。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 1. PostgreSQLの基本構成 PostgreSQLの基本的な構成について説明します。はじめに、主なプロセス、メモリー、および、ファイルについての構成図を示します。 図1 PostgreSQLの基本構成 PostgreSQLを構成する主なプロセス、メモリー、ファイルについて、その用語と概要を説明します。 リスナープロセス
ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝
弊社では、RDBMSにPostgreSQLを利用して数年間サービスを運営しています。 PostgreSQLはMySQLと違って、Webサービスでの運用事例をあまり見かけないので、今回は弊社サービスの「夜行バス比較なび 」でどのように運用しているかを紹介いたします。 システムの特徴 ユーザからのアクセスは、9割が参照処理。 データはバッチ処理で、随時 ( 毎分 ) 更新されている。 参照SQLの結果はmemcachedを利用してキャッシュをしているが、データの更新頻度が高いため長時間のキャッシュはしていない。 参照SQLは、集計処理が多いため比較的重いSQL。 参照対象となるテーブルのデータ量は、最大で数100万レコードと比較的少ない。 24/7で稼働。 構成 AWSのEC2上に、PostgreSQL 9.3を導入しています。c4系のインスタンスを使いたいので、RDSは使っていません。インス
【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました | DevelopersIO
【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました はじめに みなさん、セキュリティチェックしていますか？(挨拶 AWS Security Hub の『AWS 基礎セキュリティのベストプラクティス v1.0.0』に新たに 25個のチェック項目(コントロール)が 追加されました。AWS公式も以下のようにアナウンスしています。 この新しいチェック項目は Security Hub の [設定 > 一般 > 新しいコントロールの自動有効化] を ON に していると自動的に追加されます。 いつのまにか CRITICAL/HIGH の項目で失敗していて、大量に通知が飛んできた方もいらっしゃるかもしれません。 本ブログで新規追加されたコントロールを簡単なコメント付きで紹介していきます。 (コントロールの題目はまだ日本
実践ハイパフォーマンスMySQL 第3版
新しい情報を盛り込み、信頼性や正確さといった目標を重視するという前版からの方針に加えて、第3版では、MySQLの動作の仕組みに関する事実だけでなく、MySQLがそのように動作する原理を伝えたいと考えて執筆されている。そうした原理の実質的な効果を示す、より具体的なストーリーやケーススタディを盛り込んで、それらをベースとして、「MySQLの内部のアーキテクチャや処理がそうなっているとしたら、実際の使用状況で実質的にどのような効果が得られるのか」、「そうした効果はなぜ重要なのか」、「結果として、MySQLは特定のニーズにどのように適しているか、あるいは適していないか」という質問に答えている。MySQL管理者やアプリケーション開発者が求める必須の知識や手法を掘り下げて、問題や課題に対して実践的な考え方と解決の手法を示す。読者のMySQLについての理解と技術を一段高いレベルに引き上げる。改訂第3版。
上記の中のRDBMS全てに加えて、クラウド時代に合わせて再設計したAurora、MySQLのフォークであるMariaDBが使用できます。 MySQL：最もシェアがあるOSSのRDBMS。 Oracle：高いシェアがある商用RDBMS。 SQL Server：高いシェアがある商用RDBMS。Windowsとの親和性が高い。 PostgreSQL：機能が豊富なOSSのRDBMS。 Aurora：AWSがクラウド時代に再設計したRDBMS。MySQL 5.6互換でMySQLの5倍高速と言われています。 MariaDB：MySQLからフォークしたRDBMS。MySQL互換。 性能向上が簡単に実施可能 Amazon RDSでは、様々なスペックのインスタンスを使用できます。最大40個のvCPUのインスタンスや244GBのメモリのインスタンスがあります。性能が不足してきたら、インスタンスのサイズを変更す
Amazon Auroraのデータを高速に『巻き戻す』Backtrack機能がリリースされました！ | DevelopersIO
2018年5月11日 Backtrackの料金情報を追加 大栗です。 個人的にAuroraのアップデートをずっと追っているのですが、アナウンスされてからリリースがされておらずずっと気になっていたBacktrackという即座に過去の状態にもどる機能がリリースされたのでレポートします。 Amazon Aurora Backtrack – Turn Back Time Announcement: Amazon Aurora Backtrack Can Move a Database Back in Time Backtracking an Aurora DB Cluster Backtrackとは？ そもそもはre:Invent 2016のBreakout Sessionで『オンライン ポイントインタイム リストア』としてアナウンスされていました。 【レポート】DAT301: Deep-dive
「Amazon RDS for Aurora Deep Dive」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々
メモったので、貼付けておきます。 間違い等あるかもしれませんが、その場合はごめんなさい。 Auroraは現在Preview中 頻繁にデプロイ・機能変更が行われている 今日の話の内容は6/2時点のもの フルマネージドなDB データベースを数分で作成可能 自動でパッチの適用 1クリックでスケールアウト S3への継続的バックアップ Amazon Aurora AWSがクラウド時代にRDBを作るとするとどうなるかを1から考えた エンタープライズグレードの可用性とOSSレベルのコストを両立 現在はLimited Preview Virginia/Oregon/Irelandリージョンで動いている 5/20よりpreviewがプロダクション環境へ移行 Beta環境はクローズ AuroraのPricing 現在は、r3シリーズのみでの提供 ライセンス料金は不要 MySQLと100%互換なので、ロックイン
Headroom.js - Give your pages some headroom. Hide your header until you need it.
Headroom.js Give your pages some headroom. Hide your header until you need it. Or install via npm/yarn: npm install headroom.js --save yarn add headroom.js What's it all about? Headroom.js is a lightweight, high-performance JS widget (with no dependencies!) that allows you to react to the user's scroll. The header on this site is a living example, it slides out of view when scrolling down and slid
[レポート] Fate/Grand Orderにおける、ディライトワークス流AWS導入＆活用術 #AWSSummit | DevelopersIO
[レポート] Fate/Grand Orderにおける、ディライトワークス流AWS導入＆活用術 #AWSSummit はじめに 2016/6/1(水) ~ 6/3(金)に開催された「AWS Summit Tokyo 2016」のDay2、General Conference SMB Track「【ディライトワークス様登壇】Fate/Grand Order における、ディライトワークス流 AWS 導入＆活用術」を聴講しましたので、レポートとしてまとめます。弊社でもソーシャルゲームのバックエンドを構築することがあり、こういったテーマは非常に関心があります。 Fate/Grand Orderとは Fate/Grand Orderは、TYPE-MOON原作のFateシリーズ「Fate/stay night」を元にして製作されたスマートフォン専用オンラインロールプレイングゲームで、iOS版とAndr
![[レポート] Fate/Grand Orderにおける、ディライトワークス流AWS導入＆活用術 #AWSSummit | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/148d66c86adf4dd67af10f04029ebb83085d1632/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F06%2Faws-summit-tokyo-2016.png)
このコードどうしてこうなってるのかという経緯を知りたい時、git blameなどのコマンドを利用することが多い。しかし、git blameだとその行を変更したcommitが分かるだけであり、経緯が結局分からないということがよくある。 そういう時にその行を変更したPRを開けるようにしたいなーと思って、いろいろやったところ、Emacsで現在見ている行を変更したPRを開けるようになったのでメモ。 特定のコミットが含まれるPull Requestを開くには 前段階として、特定のコミットが含まれるPull Requestを開くということをやってみる。これは既にいろいろやっている人がいて Commit Hash から、該当 Pull Request を見つける方法 - Qiita How to find pull-request by a commit sha - Pitr.ch Gitベースのコード
MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズの Kubernetes 基盤を開発している Neco プロジェクトの ymmt です。 サイボウズ製品のほとんどはデータベースとして MySQL を採用しています。 現在 400 を越える MySQL のインスタンスを運用しており、これら全てを新しい Kubernetes 基盤に移行していく予定です。 Kubernetes 上でアプリケーションやミドルウェアの運用を自動化するソフトウェアのことをオペレーターと言います。 大量の MySQL インスタンスを Kubernetes 基盤に移行するにはオペレーターが必須であると考え、技術顧問の @yoku0825 さんの監修の下で MOCO というソフトウェアを開発しオープンソースライセンスで公開しました。 本記事では Kubernetes 上の MySQL オペレーターの状況と、開発した MOCO の機能を詳細に解説いたします。 M
こんにちは、インフラ部門のYanaです。 本日は、弊社で利用しているPostgreSQLのバックアップ取得方法についてご紹介します。 弊社は、データベースにPostgreSQL8.4系を利用しています。 定期的なバックアップとして一般的なpg_dumpも利用していますが、 データベース容量が数100GBになると数時間バックアップ時間を要してしまいます。 通常はこのバックアップ時間でも問題ありませんが、サービスの運用上この時間を許容できないシーンがありました。 バージョンアップの作業時間を短縮することが目的 弊社では、3ヶ月に1回提供アプリケーションのバージョンアップが行われます。 その際に、作業内容によってはデータベースの変更が行われます。 万が一、作業で問題があった場合は作業前の状態にロールバックする必要があります。 そのため、メンテナンス画面を表示し、リクエストの遮断した後にデータベー
Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 | Amazon Web Services
Amazon Web Services ブログ Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 本記事は、Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1 を翻訳したものです。 Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換)は 2024 年 10 月 31 日に標準サポートの終了が予定されています。Amazon Aurora MySQL バージョン 2 の標準サポートの終了タイムラインについて
AWS でバックアップを保護するためのセキュリティベストプラクティス Top 10 | Amazon Web Services
Amazon Web Services ブログ AWS でバックアップを保護するためのセキュリティベストプラクティス Top 10 この記事は “ Top 10 security best practices for securing backups in AWS ” を翻訳したものです。 セキュリティは AWS とお客様の間で責任を共有することで実現されます。ここで、お客様は AWS で安全にバックアップを行う方法を求めています。この記事では AWS 上のバックアップデータの保全とその操作に関して、厳選したセキュリティベストプラクティスのトップ 10 を紹介します。この記事では AWS Backup サービスにおけるバックアップデータと操作に焦点を当てて紹介しますが、推奨されるセキュリティのベストプラクティスは AWS Marketplace で提供されるバックアップツールなど、他のバッ
pt-online-schema-changeと5.6 InnoDBのオンラインALTER TABLE使い分け
この記事は MySQL Casual Advent Calendar 2015 の9日目です。 MySQL 5.6から InnoDBのオンラインDDL が導入されて久しいですが、一方で pt-online-schema-change (以下pt-osc）もまだまだ元気です。MySQL 5.5とそれより前ではpt-osc一択になりますが、MySQL 5.6とそれ以上の場合はInnoDBさんに任せるかpt-oscを使うかを選択することができます。 MySQL 5.6でもpt-osc一択にしても構わないといえば構わないんですが、いくつかのケースではInnoDBさんに任せた方が速くなったり安定したりするので、そのあたり解説していきます。 TL;DR ウチの使い分け。 原則 pt-osc スレーブの台数が多すぎない かつ データ容量が馬鹿でかくてストレージ食いつぶしそう または INSERT大杉で2
ストリーミング・レプリケーション (Streaming Replication) は、PostgreSQL 9.0 以降で利用できる、本体組み込みのレプリケーション機能です。参照/更新が可能な1つのマスタDBへの更新操作を、参照のみが可能な複数のスタンバイDBへ転送することで、データベースを複製することができます。スタンバイDBに更新結果が反映されるまでには若干の遅延がありますが、比較的 遅延は少なく、マスタDBへの影響も小さいレプリケーション方式です。 用途 ストリーミング・レプリケーションには以下の用途があります。 多数の参照クエリのサーバ間分散 マスタDB異常時の迅速なフェイルオーバー (切り替え) マスタDBのディスク故障に備えたリアルタイム・バックアップ PostgreSQL 9.1 での強化点 バージョン 9.0 の目玉機能として登場したレプリケーション機能ですが、9.1 では
PostgreSQLアーキテクチャ入門（PostgreSQL Conference 2012）
2. 自己紹介 • 氏名 – 永安 悟史 （ながやす さとし） • 略歴 – 2004/4-2007/9 （3年6ヵ月） • 株式会社NTTデータ入社。 • PostgreSQLによる並列分散RDBMSの研究開発。 • SIプロジェクトの技術支援、並列分散PostgreSQLミドルウェアの製品サポートおよび保守。 – 2007/10-2008/9 （1年） • データセンタ企画部門にて、次世代ITプラットフォームサービスの企画・開発。 – 2008/10-2009/10 （1年1ヵ月） • データセンタ運用部門にて、OSS系システムの基盤保守・運用、および運用チームの統括。 • 株式会社NTTデータ退職。 – 2009/11- • アップタイム・テクノロジーズ創業（共同創業者兼CEO）。 • 専門分野 – データベースシステム、並列分散システム、クラスタシステム – オープンソース・インフ
AWSアカウント間のS3, DynamoDBデータ移行計画の記録（データ完全性検証方法の検討） | DevelopersIO
こむろ＠事業開発部です。 前回 の続きです。 そろそろ諸々の記憶が薄れ始めている頃なので早めに全部書ききっておきたいところです。 前回までのまとめ データの取得と転送方法についての検討は終わりました。 Amazon S3 の転送方法の検討と想定される時間の計測 → 完了 Amazon ElastiCache for Redis の転送方法の検討と想定される時間の計測 → 完了 Amazon DynamoDB の転送方法の検討と想定される時間の計測 → 完了 転送対象の絞り込み → 完了 重要データ、ログイン情報の3テーブルにフォーカスを絞る 認証情報は除外 データ完全性検証の方法検討 → 未着手 全体のスケジュール作成 → 未完成 転送作業の実施 → 未着手 今回のテーマ データ完全性検証の方法を検討します。 データ完全性検証について。ここでは、「移行元のデータ」と「移行先のデータ」が完全
Amazon DynamoDB がニーズに合うかどうかを判断し、移行を計画する方法 | Amazon Web Services
Amazon Web Services ブログ Amazon DynamoDB がニーズに合うかどうかを判断し、移行を計画する方法 AWS CTO のワーナー・ヴォゲルスは、AWS の仕事は「企業の痛みを管理すること」だという冗談を言うことがよくあります。これは、AWS のお客様が直面する IT 面での課題の大半における本質を突く言葉です。「お客様に最大のメリットをもたらすことができるのはどこか」と呼び掛けるだけで、しばしばデータベースと関連するライセンス費用、パフォーマンスとスケーラビリティの管理、そして専門的なデータベース管理者の人件費に関する話し合いが始まります。Amazon DynamoDB などの完全マネージド型の NoSQL データベースサービスは、これらの課題に対応し、多くのメリットをもたらします。 このブログ記事では、お使いのアプリケーションに対するデータベースサービスの候
サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは本日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。
RDBMS in the Cloud: PostgreSQL on AWSを読んでみた | DevelopersIO
はじめに AWSにはRDSというマネージドなデータベースサービスがあることは皆さんご存知だと思います。そこで提供されているデータベースは、MySQL、Oracle、SQLServerの3種類です。そうです、PostgreSQLが無いのです！ナイナイ詐欺のAWSなので、そのうち出てくると思いますが、今のところはありませんので、自前で構築する必要があります。せっかく構築するなら、オンプレのコピー感覚で使うのではなく、クラウドネイティブに使いたいものです。今回は、そんなPostgreSQLをEC2上で構築するために考えるポイントをまとめたホワイトペーパーをベースに理解を深めたいと思います。 PostgreSQL on Amazon EC2 PostgreSQLは、ACID(Atomicity:原子性, Consistency:一貫性, Isolation:独立性, Durability:永続性)
この記事は本番環境でやらかしちゃった人のアドベントカレンダー9日目の記事です。 https://qiita.com/advent-calendar/2020/yarakashi-production 去年に引き続き、今年も参加させてもらいました。 ※去年の記事はこちら→ データ移行をしただけなのに…（起こってしまったメール誤配信） 今年のネタも15年くらい前の事で、且つ自分が直接関わった事案ではないのですが、「そういやあの事件、今MySQLだったらどうするかな」と思い書くことにしました。 何があったか もうタイトルで出落ちしていますが本番でUPDATE文を実行する際にWHERE句を付け忘れたという事故です。 当時の状況を整理するとこんな感じだったと思います。 対象サービス： 年商10億円くらいの自社サービス 作業内容： 仮登録されている顧客の情報を指定された情報で更新する 作業環境： DB
AWS Backup を使った Amazon RDS インスタンスの継続的なバックアップとポイントインタイムリカバリ | Amazon Web Services
Amazon Web Services ブログ AWS Backup を使った Amazon RDS インスタンスの継続的なバックアップとポイントインタイムリカバリ このブログはKelly Griffin (Solutions Architect at AWS specializing in Storage and Cloud infrastructure solutions)によって執筆された内容を⽇本語化した物です。原⽂はこちらを参照して下さい。 2021年3月10日に、AWS Backupは、Amazon Relational Database Service（Amazon RDS）の継続的なバックアップとポイントインタイムリカバリー（PITR）のサポートを発表しました。この機能により、お客様はAmazon RDSのバックアップデータを保持期間内の指定された時間から復旧することができ
2018年9月14日紙版発売 2018年9月14日電子版発売 勝俣智成，佐伯昌樹，原田登志 著 A5判／320ページ 定価3,608円（本体3,280円＋税10%） ISBN 978-4-297-10089-6 ただいま弊社在庫はございません。 →本書の新版が発行されています。 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 長年，現場で培った設計・運用計画の鉄則！ 本書はPostgreSQL 10をベースに解説しています。本書では「PostgreSQLを学習，もしくは利用したことがある人」「今後，本格的にPostgreSQLの運用管理や技術力の向上を図りたいと思っている人」を主な対象読者としています。PostgreSQLのコアな技術力を持つ専門家の視点から，システム構築や運用時に重要な要素を，PostgreSQLの内部構造と照らし合わせる形で解説します。内部
AWS Solutions Architect ブログ
こんにちは、ソリューションアーキテクトの舟崎です。 4/26(火)に開催しましたAWS Black Belt Online Seminar「AWSで使うMongoDB 」の資料が公開されました。 また、頂いたOnline Seminarで頂いたご質問とその回答が以下になります。こちらも併せてご覧ください。 Q1: MongoDBのシャードの追加・削除/ノードのスケールアップに関しては、メンテナンスなどを使用せずオンラインで実施できますでしょうか？ 止められるなら確認等の意味で安心ではありますが、シャーディングのシャード追加・削除は完全にオンラインで可能ですし、スケールアップもレプリカセットのメンバーを1台ずつローリングでスケールアップすることで実施可能です Q2: 別リージョンのレプリカセットに接続するにはVPNを利用する想定でしょうか？ インターナルな接続であればVPNを使用する想定です
[レポート]Amazon RDS for Aurora Deep Dive #AWSSummit | DevelopersIO
AWS Summit Tokyo 2015のTA-02: Tech Deep Dive by Amazon:「Amazon RDS for Aurora Deep Dive」のレポートです。 スピーカーはAmazon Data Services Japanの星野豊氏です。 レポート Auroraは現在Preview中 →頻繁に更新が行われている →今回の内容は2015/6/2現在の内容のため注意。 →今後も続々と機能追加がされる予定。 Auroraの概要 RDS→データベースを簡単に データベースを数分で作成可能 S3へのバックアップがあり、リカバリも簡単 Amazon Aurora re:Invent 2014で発表された、RDSの新しいエンジン AmazonがRDBを一から作ったらどうなるか？がコンセプト 新しい技術的チャレンジを多く盛り込んでいる エンタープライズレベルの可用性とOS
![[レポート]Amazon RDS for Aurora Deep Dive #AWSSummit | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/823f7aca4a5fc29780be05be8d6f7645655fcd6c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F05%2Faws_summit_tokyo_2015.png)
自分のAWS利用歴は2年と3ヶ月。 Summitは初参加だったが、刺激と面白さを再発見させてもらった。 また次回も行きたいと思えるイベントだったので、今日とったメモ+感想を晒しておく。 ※ memo部分はあくまで話聞きながら個人でとったメモなのでワードだけな部分も多いです。 感想もあくまで個人の感想です。 主に聞いたセッションはWeb,ゲーム系。 こんなこと言ってなかったぞ！ってとこがありましたらご指摘いただけると幸いですm(__)m Timetable AWS+Windows(C#)で構築する.NET最先端技術によるハイパフォーマンスウェブアプリケーション開発実践 登壇者 株式会社グラニ CTO 河合氏 感想 事例としては何回かwebで見たことがある。 DBの水平分割disにはヒヤヒヤ。前職の方が聞いたらなんと仰るか怖い。 ギルドバトルの負荷については同じような経験をしているので共感でき
こんばんは。最近、MySQLじゃなくPostgreSQLを触っていますが、心はいつもMySQL派な @marcy_terui です。 この記事は MySQL Casual Advent Calendar 2014 の15日目の記事です。 ちょっと16日目にかかってしまったので、怒られやしないかとgkbrしてま（ｒｙ MySQL Casual Advent Calendar 2014 - Qiita 「Amazon RDS」vs「オレオレRDS的な何か」 #とは ベンチマーク対決とかじゃありません。 日頃お世話になっている便利なRDSさんですが、そんな便利さに甘んじて… 「RDS以外でまともにMySQLを運用できない」 なんてことにならぬよう、 「俺のRDS」が「Amazon RDS」にどこまで迫れるか 的な意味での対決になります。 また、その無駄な車輪の再発明を通して、改めてMySQL及び
※この投稿は米国時間 2022 年 2 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Spanner の概要Cloud Spanner は、エンタープライズ クラスのグローバルな分散型外部整合性データベースであり、無制限のスケーラビリティと業界最高水準の 99.999% の可用性を提供します。メンテナンスの時間枠を必要とせず、使い慣れた PostgreSQL のインターフェースを提供します。リレーショナル データベースの利点と、非リレーショナル データベースの比類ないスケーラビリティと可用性を兼ね備えています。 企業が技術スタックをモダナイズし、簡素化する中で、Spanner は、新しいアプリケーションや顧客体験の構築の一環として、データベースに対する考え方や利用方法を変革するユニークな機会を提供します。 しかし、ワークロードに合わせてデータ
Geekなぺーじ : 長野の空を飛ぶLISP実験
Lispと言えば言語を連想される方々も多いと思いますが(参考1、参考2、参考3)、最近はLISP(Locator/ID Separation Protocol)というプロトコルがIETFで盛り上がっています。 Locator/IDをテーマとしているクセに、そのプロトコルのロケータである筈の名前が恐ろしく紛らわしいという点に微妙な疑問を感じつつも、このLISPは面白いプロトコルだと思います。 LISPは名前の通り、ロケータとIDを分離するものです。 考えの根本としては、先日紹介したNSFの新プロジェクトで研究されているNDN(Named Data Networking)/Contents Centric Networkingに近いとも言えそうです(参考：未来インターネットアーキテクチャ)。 しかし、LISPとNDNの大きな違いは、かなり先の未来を想定しているNDNと比べるとLISPの方が地に
2018年11月10日、Sansan株式会社が主催するイベント「Sansan Builders Box」が開催されました。Sansan史上初となるサービス開発に携わるものづくりのメンバーを中心とした本カンファレンスでは、ソフトウェア開発やプロダクトマネジメント、UXデザイン、研究開発など、様々な分野での活動の成果が発表されました。プレゼンテーション「Sansanにおけるインフラから見たRDBMSの運用」に登場したのは、Sansan株式会社Sansan事業部、プロダクト開発部インフラエンジニアの岩下訓氏。Sansanのインフラの裏側と、RDBMSの運用について語ります。講演資料はこちら 写真：山平敦史／写真提供：Sansan株式会社 Sansanにおけるインフラから見たRDBMSの運用 岩下訓氏：「Sansanにおけるインフラから見たRDBMSの運用」ということで、インフラ枠の最後という感じ
あと10分くらいでテポドン発射
1 ：名前書いたら負けかなと思っている。：2006/07/05(日) 03:27:11 ID:Gp2v326o0 怖い 2 ：名前書いたら負けかなと思っている。：2006/07/05(日) 03:29:14 ID:+rD3dC4d0 わくわく 3 ：名前書いたら負けかなと思っている。：2006/07/05(日) 03:30:22 ID:DloWfVlR0 どきどき 4 ：名前書いたら負けかなと思っている。：2006/07/05(日) 03:42:04 ID:Am7v3t6l0 __, -──- ､ ／ ／ ｀ヽ / ,' ＼ / ! / / , , } ヽ ヽ ,' │ {, 'i ィレ'レ| ハ ﾊ ! ﾊ ,ｲ | |‐‐‐-､ レ' _ﾑ__!_i/ ! } ~ ﾚ､ i ,ィ≠､ ___ }ノ
論文DynamoDB 2022に関するいくつかのメモ
PingCAPはエンタープライズ向けのソフトウェアサービスプロバイダーとして2015年に設立され、オープンソースでクラウドネイティブなワンストップのデータベースソリューションを提供することにコミットしています。PingCAPの代表的なプロジェクトであるTiDBは、オープンソースの分散型ハイブリッド・トランザクション/分析処理（HTAP）データベースで、水平方向の拡張性、強力な一貫性、MySQLとの互換性を備えた高い可用性を特徴としています。 ※このブログは2022年8月12日に公開された英語ブログ「Some Notes on the DynamoDB 2022 Paper」の拙訳です。 著者: Ed Huang (PingCAP共同創設者兼CTO) 編集者: Fendy Feng, Tom Dewan DynamoDBが論文を発表してから長い時間が経ちました。数日前、私はその新しく出版され
Dynamoの論文 規模が大きくなるにつれて、RDBMSの課題に直面 スケーラビリティ 処理能力を向上させるのが難しい。データの再配置、より大きなHWを導入するなどの対処が必要。 可用性 RDBMSは可用性よりもデータの整合性を重視する設計 トランザクション処理が不要な場面でも、全てはトランザクションとして処理される�パフォーマンスのオーバーヘッド大 AWS上に「サービス」として実装 Amazon Dynamoをサービス化したものではないので注意 パフォーマンスのために堅牢性・可用性を妥協しない 常に低レイテンシーで応答を返す 開発者（利用者）はスケーラビリティを気にしなくて良く、いつでも簡単に増減できる サーバーやディスク台数ではなく、シンプルに必要な読み書きの性能数値を指定するだけ 管理作業が不要 consistent, single-digit millisecond latenc
Amazon Dynamo DB グローバルテーブル 東京リージョン対応のお知らせ | Amazon Web Services
Amazon Web Services ブログ Amazon Dynamo DB グローバルテーブル 東京リージョン対応のお知らせ みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 Amazon DynamoDBのグローバルテーブル機能が東京リージョンに対応しましたのでお知らせいたします。 DynamoDBはどのような規模でも信頼性が高いパフォーマンスを維持できる、完全マネージド型の非リレーショナルデータベースです。グローバルテーブルの機能により、マルチリージョン、マルチマスターのデータベースを構築することが可能となり、そのレイテンシーを 10 ミリ秒未満に維持できるようになります。選択した AWS リージョンにテーブルの更新内容を自動的にレプリケーションすることができ、また、グローバルテーブルを使用して、DynamoDB
ストリーミング・レプリケーション (Streaming Replication) は、PostgreSQL 9.0 以降で利用できる、本体組み込みのレプリケーション機能です。参照/更新が可能な1つのマスタDBへの更新操作を、参照のみが可能な複数のスタンバイDBへ転送することで、データベースを複製することができます。スタンバイDBに更新結果が反映されるまでには若干の遅延がありますが、比較的 遅延は少なく、マスタDBへの影響も小さいレプリケーション方式です。 用途 ストリーミング・レプリケーションには以下の用途があります。 多数の参照クエリのサーバ間分散 マスタDB異常時の迅速なフェイルオーバー (切り替え) マスタDBのディスク故障に備えたリアルタイム・バックアップ PostgreSQL 9.1 での強化点 バージョン 9.0 の目玉機能として登場したレプリケーション機能ですが、9.1 では
RDS for MySQL にできて Aurora にできない 2 つのこと | はったりエンジニアの備忘録
Amazon Aurora への移行検証の中で、RDS for MySQL にできて Aurora にできないことを見つけました。 MySQL との高い互換性は確認できたのですが、運用する上でハマりそうです。 レプリケーションを一時停止できない MySQL にはレプリケーションを一時停止するために STOP SLAVE が用意されています。 RDS の場合は権限がないため mysql.rds_stop_replication というストアドプロシージャを使います。 mysql.rds_stop_replication - Amazon Relational Database Service どういうときにレプリケーションを止めたいかというと、分析のためにある時点（たとえば深夜 0 時）の全データをエクスポートしたいときです。 RDS の Restore to Point in Time (
「私たちはGoogle Cloud Platformがあなたのデータベースワークロードにとってベストなパブリッククラウドとなる努力を続けていくことを約束します」―8月16日（米国時間）、Googleは同社のパブリッククラウド「Google Cloud Platform（GCP）」が提供するデータベース関連サービスでいくつかの重要なアップデートを行いました。今回はそれらの発表内容を紹介しながら、Googleのパブリッククラウド戦略について検証してみたいと思います。 Advancing enterprise database workloads on Google Cloud Platform : Google Cloud Platform Blog MySQLインスタンスの「Cloud SQL」などがGAに 16日のリリース内容は大きく2つに分かれています。ひとつはこれまでベータ提供
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLのアーキテクチャー概要｜PostgreSQLインサイド
AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば
PostgreSQLでWebサービスを運用するためにやっていること - LCL 開発者ブログ
AWS再入門 Amazon RDS編 | DevelopersIO
Emacsで現在見ている行を変更したPRを開けるようにした - $shibayu36->blog;
株式会社シャノン技術ブログ: 数百GBのPostgreSQLを一瞬でバックアップする方法
ストリーミング・レプリケーション | Let's POSTGRES
奮闘記その６３:PostgreSQLのWAL機能、PITR、障害復旧の話
とあるテーブルの中身を一括更新した話から学ぶPITR - Qiita
［改訂新版］内部構造から学ぶPostgreSQL 設計・運用計画の鉄則
AWS Summit 2014 2日目に行ってきた - Qiita
「Amazon RDS」vs「オレオレRDS的な何か」（序章） - misc.tech.notes
Cloud Spanner の誤解を打ち破る | Google Cloud 公式ブログ
Sansanのインフラから見たRDBMS運用の裏側 PostgreSQLの構成から活用事例まで解説
AWS Black Belt Tech シリーズ 2015 - Amazon DynamoDB
ストリーミング・レプリケーション | Let's POSTGRES
第8回 クラウドデータベースの大幅強化に見るGoogleのパブリッククラウドへの本気度 | gihyo.jp