Guten Morgen Phillip, Master of Mongo Clusters. Danke für die Info und Umstellung. Natürlich Können Mit freundlichen Grüßen Haiko Gerdes - Geschäftsführer - ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749 Mobil: +49 172 610 2849 Internet: http://traso.de E-Mail: h.gerdes@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 Von: team [mailto:team-bounces@lists.traso.de] Im Auftrag von Phillip Wirth Gesendet: Montag, 5. Mai 2014 09:24 An: team@lists.traso.de Betreff: Re: [Team] Mongo mal wieder Done, beide mongos sind hoch und rennend. Rsync wurde am Freitag gemacht hat bis Samstag nacht gedauert, kurz bevor wieder heftig in die db geschrieben wurde, Glück oder können? ;) Hier die DBS mit Index und ohne Fragmentierung: mongos> show dbs; DAF_LIVE_loging 3.9521484375GB DEV_DEVEL_data 23.9423828125GB DEV_DEVEL_loging 0.203125GB DEV_STAGING_data 3.9521484375GB DEV_STAGING_loging 0.203125GB FER_LIVE_data 35.9365234375GB FER_LIVE_loging 19.9443359375GB FER_STAGING_loging 0.203125GB FOR_LIVE_loging 3.9521484375GB HOCL_LIVE_data 23.9423828125GB HOCL_LIVE_loging 0.453125GB JT_LIVE_data 161.875GB JT_LIVE_loging 59.9248046875GB JT_STAGING_loging 0.203125GB JT_TEST_loging (empty) LMX_LIVE_data 147.8818359375GB LMX_LIVE_loging 101.904296875GB LMX_STAGING_loging 0.203125GB LTS_LIVE_loging 47.9306640625GB OPD_LIVE_data 109.900390625GB OPD_LIVE_loging 15.9462890625GB OPD_STAGING_loging 0.203125GB XPUR_LIVE_loging 5.951171875GB admin (empty) config 0.046875GB loging 0.203125GB test 0.078125GB mongos> Enjoy your Mongo experience ;) Am 02.05.2014 09:26, schrieb Phillip Wirth: Lösung: Wie schon im Teammeeting gesagt: Die Daten die drin sind sind theoretisch brauchbare Daten, keine zu alten etc. Da lag ich wohl falsch. Beim letzten Mongo Rsync wurden bei JT zwei idexes eingeführt. Dies sind besondere Indexe denn denen gibt man einen TTL Wert mit, wie lang eben dieser Datensatz erhalten bleiben soll bevor er automatisch gelöscht wird. Es handelt sich hierbei um 2 Indexe, einen auf der process collection und einen auf der request collection. Bei JT, OPD und XPUR exestieren auf beiden collections diese Indexe. Bei allen anderen nur auf process. Warum? Es wurde nie in die deplyment TODOs aufgenommen: //Nach 8 Tagen ausführen nach dem Deployment ausführen db.request.remove({"createdAt" : { "$exists" : false}}) //Sofort ausführen db.request.ensureIndex({"createdAt" : 1}, {background : true, expireAfterSeconds: 691200}) Diese Indexe bewirken bei uns das die Daten nach 8 Tagen nach was aufch immer in createdAt automatisch gelöscht werden! Außerdem schalten sie für die collection usePowerOf2Sizes (http://docs.mongodb.org/manual/reference/command/collMod/#usePowerOf2Sizes) an, bedeutet letztendlich weniger Fragmentierung. Also was ich gemacht habe: Während des betriebs die oben genannten Statements abgesetzt. Dabei galt sicherzustellen das die mongo noch "erreichbar" ist denn nebenbei wurde die Updateliste für HBD abgearbeitet. So gesehen war der erste ReSync platt gesehen umsonst, aber diese 200 GB vorerst loszuwerden und dann quasi diesen Puffer für indiexe etc. zu nutzen hat auch seinen vorteil. Denn auch usePowerOf2Sizes kostet anfangs etwas mehr Platten-Kapazität. Was zu tun ist: Alles kontrollieren, ob nun die Indexes gleich sind, überall. Beide mongo07 und mongo08 resyncen lassen. Theoretically done. Am 30.04.2014 12:31, schrieb Phillip Wirth: Auflistung der Daten: Datenbanken: connecting to: mongo08.luan.xres.de/test mongos> show dbs; DAF_LIVE_loging 15.9462890625GB DEV_DEVEL_data 23.9423828125GB DEV_DEVEL_loging 0.203125GB DEV_STAGING_data 3.9521484375GB DEV_STAGING_loging 0.203125GB FER_LIVE_data 35.9365234375GB FER_LIVE_loging 117.896484375GB FER_STAGING_loging 0.203125GB FOR_LIVE_loging 11.9482421875GB HOCL_LIVE_data 21.943359375GB HOCL_LIVE_loging 1.953125GB JT_LIVE_data 161.875GB JT_LIVE_loging 57.92578125GB JT_STAGING_loging 0.453125GB JT_TEST_loging (empty) LMX_LIVE_data 145.8828125GB LMX_LIVE_loging 169.87109375GB LMX_STAGING_loging 0.203125GB LTS_LIVE_loging 273.8203125GB OPD_LIVE_data 109.900390625GB OPD_LIVE_loging 43.9326171875GB OPD_STAGING_loging 0.203125GB XPUR_LIVE_loging 5.951171875GB ======================================== Database Statistics von oben Rot markierten (AUSGABEN IN GB!) http://docs.mongodb.org/manual/reference/command/dbStats/#dbcmd.dbStats FER mongos>db.stats(1024*1024*1024) { "raw" : { "production/mongo07:10003,mongo08:10003" : { "db" : "FER_LIVE_loging", "collections" : 8, "objects" : 56529329, "avgObjSize" : 2044.447189670339, "dataSize" : 107, "storageSize" : 110, "numExtents" : 123, "indexes" : 7, "indexSize" : 3, "fileSize" : 117, "nsSizeMB" : 16, "dataFileVersion" : { "major" : 4, "minor" : 5 }, "ok" : 1 } }, "objects" : 56529329, "avgObjSize" : 2044, "dataSize" : 107, "storageSize" : 110, //Tatsächliche Größe der Collection "numExtents" : 123, "indexes" : 7, "indexSize" : 3, "fileSize" : 117, //Belegt auf der Platte (stoargeSize + Padding etc.) "ok" : 1 } LMX /* 0 */ { "raw" : { "production/mongo07:10003,mongo08:10003" : { "db" : "LMX_LIVE_loging", "collections" : 9, "objects" : 60985004, "avgObjSize" : 2732.994838731174, "dataSize" : 155, "storageSize" : 161, "numExtents" : 176, "indexes" : 8, "indexSize" : 3, "fileSize" : 169, "nsSizeMB" : 16, "dataFileVersion" : { "major" : 4, "minor" : 5 }, "ok" : 1 } }, "objects" : 60985004, "avgObjSize" : 2732, "dataSize" : 155, "storageSize" : 161, "numExtents" : 176, "indexes" : 8, "indexSize" : 3, "fileSize" : 169, "ok" : 1 } LTS { "raw" : { "production/mongo07:10003,mongo08:10003" : { "db" : "LTS_LIVE_loging", "collections" : 8, "objects" : 25003047, "avgObjSize" : 11474.23359320966, "dataSize" : 267, "storageSize" : 268, "numExtents" : 191, "indexes" : 8, "indexSize" : 1, "fileSize" : 273, "nsSizeMB" : 16, "dataFileVersion" : { "major" : 4, "minor" : 5 }, "ok" : 1 } }, "objects" : 25003047, "avgObjSize" : 11474, "dataSize" : 267, "storageSize" : 268, "numExtents" : 191, "indexes" : 8, "indexSize" : 1, "fileSize" : 273, "ok" : 1 } Betroffen sind hier jewails die process und request collection. Von SRK nachgefragte Collection von LMX: LMX_LIVE_loging.log_provicer_payload mongos> db.log_provider_payload.stats(1024*1024*1024) { "sharded" : false, "primary" : "production", "ns" : "LMX_LIVE_loging.log_provider_payload", "count" : 2167248, "size" : 57, "avgObjSize" : 0.000026300635644836218, "storageSize" : 59, //Das hier sind GB "numExtents" : 50, "nindexes" : 1, "lastExtentSize" : 1, "paddingFactor" : 1, "systemFlags" : 1, "userFlags" : 0, "totalIndexSize" : 0, "indexSizes" : { "_id_" : 0 }, "ok" : 1 } Am 30.04.2014 10:40, schrieb Haiko Gerdes: Hallo Phillip, danke für Info und Lösung. Mit freundlichen Grüßen Haiko Gerdes - Geschäftsführer - ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749 Mobil: +49 172 610 2849 Internet: http://traso.de E-Mail: h.gerdes@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 -----Ursprüngliche Nachricht----- Von: team [mailto:team-bounces@lists.traso.de] Im Auftrag von Phillip Wirth Gesendet: Mittwoch, 30. April 2014 09:41 An: team@lists.traso.de Betreff: [Team] Mongo mal wieder Huhu, Da einige vielleicht es durch Nagios Meldungen schon mitbekommen haben die Mongo hat noch 1 Woche zu leben bevor sie umkippt weil Platten voll. SetUp: SECONDARY: mongo08 PRIMARY: mongo07 jewails mit ~1,6 TB Plattenplatz Was bisher geschah: Unsere Vermutung Fragmentierung der Daten. gestern gegen 11 Uhr am : Krisztian und Ich haben mongo08 's Daten gelöscht, und resyncen lassen. Gestern Abend habe ich den HBDImporter gestoppt weil das oplog (Quasi das bin log für mongo) sonst too stale würde und mongo08 würde nicht hinterherkommen mit syncen - oplog größer machen? Ja! In dem SetUp möglich? Nein. Grund? Plattenplatz. Das ging ganz gut, habe jetzt den mongo08 zum master gemacht. !!!ABER!!! Die aktuellen unfragmentierten Daten auf mongo08 sind 1,4 TB du -sh /var/lib/mongodb/production => 1,4T /var/lib/mongodb/production Und zu 1,6TB ist nicht viel Luft nach oben! Ich habe gestern Abend auch was meinen Bereich betrifft nach unnützen Daten geschaut, aber die Menge ist so gering das es im MB Bereich bleibt. Aktuell: HBDImporter gestartet. Was jetzt ansteht ist der resync von mongo07, das werde ich tun wenn der HBDImporter zu ~90% durchgelaufen ist. Dann ist die Gefahr sehr gering das dass oplog zu stale wird. Gerade noch mit Soeren gesprochen: Die Caheberechnung und alle anderen Prozesse sollten problemlos weiter laufen. Viel Spaß, Phillip -- Mit freundlichen Grüßen Phillip Wirth - Entwicklung - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig E-Mail: p.wirth@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 _______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team -- Mit freundlichen Grüßen Phillip Wirth - Entwicklung - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig E-Mail: p.wirth@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 _______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team -- Mit freundlichen Grüßen Phillip Wirth - Entwicklung - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig E-Mail: p.wirth@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850