MongoDB 3.6 Release Notes 翻訳 - Qiita
Release Notes for MongoDB 3.6の翻訳です。原文はMongoDB Documentation Teamによるものです。ライセンスはCC BY-NC-SA 3.0となっています。 CONTRIBUTING.rst MongoDB documentation is distributed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license. 脚注は、リリースノート以外の3.6のマニュアルなども参考にして今回付け加えたものです。 MongoDB 3.6 リリースノート セキュリティ デフォルトでlocalhostにのみバインド MongoDB 3.6から、MongoDBのバイナリ（mongodおよびmongos）は、デフォルトではlocalhostにのみバイ
俺でもわかるシリーズ: MongoDBのレプリケーション - Qiita
この記事はMongoDB Advent Calendar 2015の17日目です。 概要 何を今更感満載のおさらい記事です。 意図せず嘘を含む可能性がゼロではないので、ドキュメント Replication — MongoDB Manual 3.0 併読推奨です。 Replica Setとは？ Replication Introduction — MongoDB Manual 3.0 Replica Setとは、MongoDBが備える強力なレプリケーションと自動フェイルオーバーの仕組みです。 複数台のMongoDBサーバーで構築されたReplica Setは、もう一つのMongoDBの強力な機能であるSharding (水平分割)においてShardとして追加することが可能です。 どちらも大規模で高可用なMongoDBデータベースを構築する際に欠かせないものであり、これを標準機能として持ってい
MongoDBでReplicaSetにメンバーを追加／削除する方法と、その注意点 - matsukaz's blog
MongoDBで、ReplicaSetにメンバーを追加／削除する方法は、Adding a New Set Memberにある通りです。 rs.add("node1:27018");で追加したり、 rs.remove("node1:27018");で削除したり。 追加する際は 既存データを物理的にコピーしてきて戻す方法 カラの状態から同期を取る方法 があります。 1000万件程度であれば、1.でも数分で終わる模様。数億件以上ある場合は、2.で戻した方が作業が早いかもしれません。 注意点1 その際に気をつける点は、local.*のファイルはコピーしてこないこと。local以外のコレクションに対応するファイルだけコピーしてきて、あとは起動後にrs.add()すればOKです。local.*がいると、データの整合が取れなくなって「still initiating」って状態で止まってしまいます。これや
Monitoring for MongoDB — MongoDB Manual
Monitoring is a critical component of all database administration. A firm grasp of MongoDB's reporting will allow you to assess the state of your database and maintain your deployment without crisis. Additionally, a sense of MongoDB's normal operational parameters will allow you to diagnose problems before they escalate to failures. This document presents an overview of the available monitoring ut
時系列データとMongoDB2.4の新機能Hash based sharding - 中年engineerの独り言 - crumbjp
実は数年前（MongoDB 1.6〜1.8の時期）にログをリアルタイムに全てmongodbに叩き込んで期間毎に解析する仕組みを作ろうとして挫折した事がある。 理由は幾つかあったのだが主に cappadコレクションでは解析時の負荷とログ投入負荷が重なってしまう。 → 最終的には書き込みが負けてoplogが溢れる。 時系列カラムをshard keyにするとchunk migrationが辛すぎる。 そもそもshardingの信頼性が・・・ という理由だった。 今ならストレージエンジンが早くなったし再挑戦しても良いかもしれない。 ログは非同期に準リアルタイムに拾って投入。 出力元＋時間でshard key。 なるべくグループコミットの効率が上がる塊を作る。 とか、、 お題 ともかく、今回は 時系列データを投入した時chunk migrationがどう動くのか？ の話。 そもそも時系列カラムをsh
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Advanced MongoDB #1
How to Determine Chunk Distribution (data and number of docs) in a Sharded MongoDB Cluster?
MongoDB chunks balancing with compound sharding key
DB tech showcase： 噂のMongoDBその用途は？
月間10億pvを支えるmongo db