Dynamiska uppdateringsfel (eller andra plattformsfel) kan vara orsaken till distribuerade informationsbasutbytesfel:
"Data tas emot från den nod för vilken konfigurationsändringar har registrerats"
"Konfigurationen av den distribuerade informationssäkerhetsnoden motsvarar inte den förväntade"
Hur återställer man utbytet?
Men låt oss börja inte med restaurering, utan med möjligheten att genomförabyta "manuellt", vilket är viktigt under dagen, för som alltid ska allt fungera "igår" :) Detta kan göras med hjälp av underbara behandlingar som jag inte kom ihågnaken där jag laddade ner den (författare, vänligen svara - jag lämnar länkar till din resurs och vid behov tar jag bort den från min). Bearbetning gör det möjligt att ladda ner endast registrerade dataändringar i databasen (enligt den specificerade utbytesplanen för en specifik nod!) i XML utan att ladda ner konfigurationsändringar och, om konfigurationsobjekten inte har förändrats mycket, då är det en mycket stor chans att ladda denna data. Dessa kan laddas ner från länken i slutet av artikeln.
När det gäller återhämtning. Det finns enklare metoder som inte inkluderar alla objekt i listan nedan, men de hjälper inte alltid, vilket var fallet i ett av mina fall. Därför presenterar jag metoden som hjälpte mig att kringgå möjliga problem på ett mer omfattande sätt. Nästa steg för steg.
Det är lämpligt att vidta dessa steg när det inte finns några fungerande användare i databasen. Om detta inte är möjligt måste du "avsluta" metoden själv, och därför måste du först förstå dess logik.
1. Gör säkerhetskopior överallt.
2. För klient-servrar: inaktivera databaserna via "serveradministration" och anslut dem omedelbart med blockering av rutinuppgifter (detta kommer att återställa servercachen). Efter detta, glöm inte att överföra registreringsloggen till den nya katalogen.
3. På alla datorer som används för återställning, ta bort databasen i listan över 1C startdatabaser och skapa en ny (användarcachen kommer att rensas)
4. I konfiguratorn (i den centrala databasen), lägg till en ny konstant och spara konf.ändringarna.
5. Rensa alla utbyteskataloger.
6. Gör lossningar till alla grenar (endast lossningar för närvarande).
7. Försök att ladda ner (endast ladda ner) mottagna data till alla filialer. Det är naturligt att acceptera konf-ändringarna.
Om allt är bra överallt går vi vidare om allt är dåligt, vi tror att det kan hjälpa att ladda .cf från den centrala databasen och LADDA den till grenen. I slavnoden bör du koppla bort databasen från RIB (bearbetning hjälper till med detta - ladda ner från länken nedan). Det finns en artikel om detta ämne på infostart.ru.
8. Vi avbryter registreringen av ändringar för filialer i centralbanken (vi har trots allt redan fått alla ändringar överallt). Det är viktigt att göra i detta skede så att de ackumulerade förändringarna från olika grenar kommer till andra grenar. (ladda ned bearbetning för obindande bindning från länken nedan).
9. Vi laddar in i centralbanken och om allt är bra, så laddar och lossar vi med varje filial flera gånger för att konsolidera resultatet.
10. Det är allt.
Du kan aktivera exekvering av rutinuppgifter för klient-serverdatabaser.
För att förhindra problem som orsakar detta fel, rekommenderas det att inte göra dynamiska uppdateringar (åtminstone flera gånger i rad - tills ändringar har laddats upp till filialer), och det är också lämpligt att markera rutan "ladda upp data endast vid framgångsrik uppladdning" i utbytesinställningarna.
Först en lista över använda förkortningar:
- RIB - distribuerad informationsbas
- CB - central bas, rotnod för RIB
- UB - fjärrbas, databas för en fjärransluten RIB-nod
Av egen erfarenhet kan jag säga att jag har stött på två orsaker till felet:
- Under mottagandet av meddelandefilen "föll" databasen i ledningssystemet, och därför skedde det tydligen en avsynkronisering mellan konf. centralbanken och UB;
- under MSSQL laddade klienten ner en kopia av arbetsdatabasen och stängde inte av reg. automatiskt utbytesuppgifter, som ett resultat genererades vissa meddelanden till fjärrnoder från arbetsdatabasen och några från en kopia, vilket ledde till avsynkronisering av konfigurationer
Det finns också en åsikt att detta fel orsakas av användningen av en dynamisk databasuppdateringsmekanism. Det finns tvivel här, för å ena sidan påverkar dynamisk uppdatering aldrig databasstrukturen, och RIB-mekanismerna fungerar fortfarande med databasstrukturen, och inte med dess tillämpade del, ändå använder RIB en mekanism för att generera en digital signatur konfigurationsversionen (i framtiden kommer jag att kalla det en hash för kort), och när applikationsdelen ändras måste hashen naturligtvis räknas om. Jag kommer varken förneka detta eller hävda det, för... Om jag stötte på den här situationen hittade jag inga tydliga bevis på det.
För att rätta till det använder jag 2 metoder, beroende på situationen.
FÖRSTA TEKNIK
Den första (vanligaste) nämns upprepade gånger både i partnerkonferensen och på andra internetresurser relaterade till 1C. Det används i de flesta fall när, trots meddelandet om avvikelser i konfigurationer, en manuell jämförelse visar att de är identiska.
Sekvensering:
- ladda ur cf-filen från centralbanken;
- vi kopplar bort UB från RIB (Set MainNode-metoden, färdig bearbetning finns i applikationen eller i andra publikationer);
- ersätter konf. UB till cf-filen som laddades upp i det första steget, för detta använder vi menyn "Ladda konfiguration från fil" (och inte jämförelse-sammanfogning!!!);
- Låt oss återställa RIB-tecknet för UX.
I de flesta fall är dessa åtgärder mer än tillräckligt för att återställa utbytet, men inte alltid...
ANDRA METOD
Den används om den första metoden inte fungerade, och det inte är möjligt att ladda ner noden igen.
Bakgrund: klienten satte upp en kaskad-RIB och ett fel inträffade i den första nivån av kaskaden (den andra nivån fungerade felfritt hela tiden). Konfigurationen har utvecklats tillsammans med kundens IT-tjänst och sedan felet inträffade har centralbankens konfiguration ändrats flera gånger. Möjligheten att rulla tillbaka ändringar övervägdes inte ens i princip, eftersom förlusten av vissa data och nedläggningen av flera avdelningar var helt oacceptabelt. Det första alternativet för att korrigera felet gav inga påtagliga resultat. Därför var vi tvungna att leta efter andra lösningar.
Idén kom att försöka ersätta hasharna för konfigurationsfiler direkt i XML-utbytesfilerna. Beskrivningen av strukturen för utbytesfilen från boken "Professionell utveckling i 1C:Enterprise 8-systemet" gav en svag uppfattning om bildandet av digitala signaturer av konfigurationer och ändringar i dem, men bestämde riktningen för sök: värdena för Digest1 och Digest2. Jag kom på allt annat rent empiriskt (det vill säga genom försök och misstag), men det var möjligt att etablera ett mönster.
Testexperiment var framgångsrika. På arbetsbaserna gick allt också bra.
Så, sekvensen av åtgärder:
- utför steg 1 - 4 i den första metoden;
- Vi laddar ut utbytesfilen från UB, men laddar den inte in i centralbanken;
- Vi laddar ut utbytesfilen från centralbanken, men laddar den inte in i UB;
- i utbytesfilen från centralbanken ersätter vi blocket som innehåller information om konfigurationsändringar och hash (Digest1 och Digest2) med ett block med hash från UB-filen (se exempel nedan)
- Vi laddar upp filen från 4:e punkten till UB;
- Se till att skriva över utbytesfilen från UB (punkt 2)! denna fil bör inte laddas ner vid utbyte med centralbanken!
- För att kontrollera gör vi flera på varandra följande byten.
Om datakomprimering används under utbytet, inaktiverar vi antingen komprimering eller packar först upp filen, ändrar den, packar den sedan tillbaka och skickar den.
Byt filblock från centralbanken
...här är block som beskriver konfigurationsändringar...
måste ersättas med ett block av utbytesfilen från UB (observera att Digest1 för en fil från UB alltid är lika med "0000000000000000000000000000000000"!!!)
De angivna åtgärderna måste utföras med yttersta försiktighet en felaktig sekvens kan resultera i att RIB inte fungerar. Därför är det OBLIGATORISKT att skapa säkerhetskopior innan dessa åtgärder!
