Ik heb een Mongo-service waarmee meerdere hosts communiceren. De host waarop de Mongo-service wordt uitgevoerd, is best bijzonder: hij heeft 3 TB RAM. Die host genereert echter ook intermitterende busfoutreacties. Als er een busfout optreedt binnen het Mongo-serviceproces, wordt de service stopgezet en krijgen alle celeryprocessen (Python) die met de bron communiceren, antwoorden van Connection Refused.
Is er een manier om de Mongo-service toe te staan op de een of andere manier herstellen van een busfout? Kan sharding helpen bij dit probleem? Is er een andere mogelijke oplossing voor de busfout die kan worden gemaakt op het configuratieniveau van de applicatie? Ik zou dankbaar zijn voor alle suggesties die anderen over deze vraag kunnen doen!
Ik heb Mongo vanaf de bron op RedHat gebouwd, zodat ik elke recente versie kan gebruiken als dat helpt. De momenteel geïnstalleerde versie is 3.6.4.
Reacties
- Busfouten komen voort uit een proces dat probeert RAM aan te pakken dat er niet is (kan niet worden geadresseerd). Ik denk dat je naar HW / moet kijken SW-compatibiliteit.
- @dezso is het niet mogelijk om dit probleem op applicatieniveau op te lossen? Ik kan in dit geval geen ' de hardware beïnvloeden, maar ik kan wel configureren de mongo-applicatie …
- Nou, zoals het klinkt, kan MongoDB het geheugen niet goed verwerken (adresseren). Dit is nauwelijks iets dat je kunt oplossen door instellingen aan te passen (maar ik zeg dit zonder MongoDB echt te kennen). Ik ' d stel voor om een probleem met de ontwikkelaars te openen, ze hebben misschien een beter idee dan wie dan ook hier.
- @duhaime, Kunt u de " Bus fout ?. Is het afkomstig van softwarelabel of hardwarelabel. Heb je " smartmontools " in linux-omgeving gecontroleerd?
- @MdHaidarAliKhan Ik denk dat deze busfout afkomstig is van de hardwareniveau, maar ik ' zou graag de uitzondering op de toepassingslaag willen opvangen …
Antwoord
Busfout afhandelen in Mongo Service
Volgens MongoDB-documentatie hier Het zou ook nuttig zijn om smartctl uit te voeren (onderdeel van smartmontools ) om te controleren op SMART-hardwarefouten:
sudo smartctl -a /dev/sdb Zelfs jij kunt het Linux fsck -hulpprogramma gebruiken om Linux-bestandssystemen te controleren en te repareren (ext2, ext3, ext4, etc.).
Afhankelijk van wanneer was de laatste keer dat een bestand systeem is gecontroleerd, voert het systeem de fsck uit tijdens het opstarten om te controleren of het bestandssysteem in een consistente staat verkeert. De systeembeheerder kan het ook handmatig uitvoeren als er een probleem is met de bestandssystemen.
Zorg ervoor dat u de fsck uitvoert op een niet-gekoppeld bestandssysteem om gegevensbeschadiging te voorkomen problemen.
Answer
Busfout is meestal een indicatie van een programmafout, in dit geval MongoDB zelf, of, zelden, een hardwareprobleem. Als zodanig is het eerste dat u moet proberen, upgraden naar de nieuwste stabiele versie. Als het probleem aanhoudt, kunt u er niet veel aan doen behalve een bugrapport indienen bij Mongo.