Först en lista över förkortningar som används:
- RIB - distribuerad informationsbas
- Centralbank - centralbasen, RIB: s rotnod
- UB - fjärrdatabas, databas för fjärr RIB-nod
Av min egen erfarenhet kan jag säga att jag stött på två orsaker till felet:
- under mottagningen av meddelandefilen i UB "föll basen", och därför fanns det tydligen en desynkronisering mellan konf. CB och UB;
- under MSSQL laddade klienten ner en kopia av arbetsdatabasen och stängde inte av kopian i kopian. Auto-exchange-uppgifter, som ett resultat, bildades en del av meddelandena till fjärrnoderna från arbetsdatabasen, och några från kopian, vilket ledde till desync-konfigurationer
Det finns också en uppfattning om att användningen av den dynamiska databasuppdateringsmekanismen leder till detta fel. Det råder tvivel, eftersom å ena sidan påverkar dynamisk uppdatering aldrig databasstrukturen, och RIB-mekanismerna fungerar fortfarande med databasstrukturen, och inte med dess applikationsdel, ändå använder RIB mekanismen för generering av digital signatur i konfigurationsversionen (i nedan kallar jag det för att minska hash), och när applikationsdelen ändras är hash naturligtvis skyldigt att återberättas. Jag kommer varken att förneka detta eller bekräfta, för om jag stötte på den här situationen, så hittade jag inga uppenbara bevis för detta.
För korrigering använder jag två metoder beroende på situationen.
FÖRSTA METODEN
Den första (vanligaste) nämns upprepade gånger i partnerkonferensen och på andra internetresurser relaterade till 1C. Det används i de flesta fall när det, trots meddelandet om skillnader i konfigurationer, när man manuellt jämförs verkar som om de är identiska.
Sequencing:
- lossa CF-filen från centralbanken;
- vi lossar UB från RIB (SetMainHousNode-metoden, klar bearbetning finns i applikationen eller i andra publikationer);
- ersätt konf. UB till CF-filen som laddats upp i det första steget, för detta använder vi menyn "Ladda konfiguration från fil" (och inte genom jämförelse-union !!!);
- vi återställer RIB: s tecken för UB.
I de flesta fall är dessa åtgärder mer än tillräckliga för att återställa utbytet, men inte alltid ...
ANDRA METODEN
Den används om den första metoden inte fungerade och det inte går att lossa noden igen.
Bakgrund: klienten konfigurerades med en kaskad RIB och ett fel inträffade i den första nivån på kaskaden (den andra nivån fungerade perfekt hela denna tid). Utvecklingen av konfigurationen genomfördes tillsammans med kundens IT-tjänst, och eftersom felet inträffade lyckades centralbankens konfiguration ändras flera gånger. Alternativet med återföring av ändringar beaktades inte ens i princip, för förlusten av vissa data och avstängningen av flera enheter var helt oacceptabelt. Den första versionen av felkorrigeringen gav inga konkreta resultat. I det här sammanhanget var jag tvungen att leta efter andra lösningar.
Idén kom upp för att försöka ersätta hasherna för konfigurationsfilerna direkt i XML-utbytesfilerna. Beskrivningen av utbytesfilens struktur från boken "Professional Development in 1C: Enterprise 8" gav en dålig uppfattning om bildandet av digitala signaturer för konfigurationer och förändringar i dem, men bestämde riktningen för sökningen: Digest1 och Digest2-värden. Jag fick reda på allt annat på ett rent empiriskt sätt (det vill säga genom prövning och fel), men det visade sig skapa ett mönster.
Testexperimenten var framgångsrika. Även på arbetsbasen gick allt bra.
Så handlingssekvensen:
- utför steg 1 till 4 i den första tekniken;
- lossa utbytesfilen från UB, men ladda inte upp den till centralbanken;
- lossa utbytesfilen från centralbanken, men ladda inte upp den till UB;
- i utbytesfilen från Centralbanken ersätter vi blocket som innehåller information om konfigurationsändringar och hash (Digest1 och Digest2) med hash-blocket från UB-filen (se exempel nedan)
- vi laddar upp filen från den fjärde artikeln till UB;
- se till att skriva över utbytesfilen från UB (2: a punkten)! Denna fil ska inte laddas upp vid utbyte med centralbanken!
- för verifiering gör vi flera utbyten i följd.
Om datakomprimeringen används under utbytet stänger vi antingen av komprimeringen, eller packar först upp filen, ändrar den, packar sedan tillbaka den och skickar den.
Blockera utbytesfilen från centralbanken
... här är blocken som beskriver konfigurationsändringarna ...
måste ersättas med ett utbytesfilblock från UB (notera digest1 filen från UB är alltid lika med "0000000000000000000000000000000000" !!!)
Dessa åtgärder måste utföras med stor försiktighet, en felaktig sekvens är full av RIB: s fullständiga driftskompatibilitet. Därför, före dessa åtgärder, är att skapa säkerhetskopior MANDATORI!
För att komma igång listar jag de förkortningar jag använder:
- RIB - distribuerad informationsbas
- Centralbank - centralbasen, RIB: s rotnod
- UB - fjärrdatabas, databas för fjärr RIB-nod
Av min egen erfarenhet kan jag säga att jag stött på två orsaker till felet:
- under mottagningen av meddelandefilen i UB "föll basen", och därför fanns det tydligen en desynkronisering mellan konf. CB och UB;
- under MSSQL laddade klienten ner en kopia av arbetsdatabasen och stängde inte av kopian i kopian. Auto-exchange-uppgifter, som ett resultat, bildades en del av meddelandena till fjärrnoderna från arbetsdatabasen, och några från kopian, vilket ledde till desync-konfigurationer
Det finns också en uppfattning om att användningen av den dynamiska databasuppdateringsmekanismen leder till detta fel. Det råder tvivel, eftersom å ena sidan påverkar dynamisk uppdatering aldrig databasstrukturen, och RIB-mekanismerna fungerar fortfarande med databasstrukturen, och inte med dess applikationsdel, ändå använder RIB mekanismen för generering av digital signatur i konfigurationsversionen (i nedan kallar jag det för att minska hash), och när applikationsdelen ändras är hash naturligtvis skyldigt att återberättas. Jag kommer varken att förneka detta eller bekräfta, för om jag stötte på den här situationen, så hittade jag inga uppenbara bevis för detta.
För korrigering använder jag två metoder beroende på situationen.
FÖRSTA METODEN
Den första (vanligaste) nämns upprepade gånger i partnerkonferensen och på andra internetresurser relaterade till 1C. Det används i de flesta fall när det, trots meddelandet om skillnader i konfigurationer, när man manuellt jämförs verkar som om de är identiska.
Sequencing:
- lossa CF-filen från centralbanken;
- vi lossar UB från RIB (SetMainHousNode-metoden, klar bearbetning finns i applikationen eller i andra publikationer);
- ersätt konf. UB till CF-filen som laddats upp i det första steget, för detta använder vi menyn "Ladda konfiguration från fil" (och inte genom jämförelse-union !!!);
- vi återställer RIB: s tecken för UB.
I de flesta fall är dessa åtgärder mer än tillräckliga för att återställa utbytet, men inte alltid ...
ANDRA METODEN
Den används om den första metoden inte fungerade och det inte går att lossa noden igen.
Bakgrund: klienten konfigurerades med en kaskad RIB och ett fel inträffade i den första nivån på kaskaden (den andra nivån fungerade perfekt hela denna tid). Utvecklingen av konfigurationen genomfördes tillsammans med kundens IT-tjänst, och eftersom felet inträffade lyckades centralbankens konfiguration ändras flera gånger. Alternativet med återföring av ändringar beaktades inte ens i princip, för förlusten av vissa data och avstängningen av flera enheter var helt oacceptabelt. Den första versionen av felkorrigeringen gav inga konkreta resultat. I det här sammanhanget var jag tvungen att leta efter andra lösningar.
Idén kom upp för att försöka ersätta hasherna för konfigurationsfilerna direkt i XML-utbytesfilerna. Beskrivningen av utbytesfilens struktur från boken "Professional Development in 1C: Enterprise 8" gav en dålig uppfattning om bildandet av digitala signaturer för konfigurationer och förändringar i dem, men bestämde riktningen för sökningen: Digest1 och Digest2-värden. Jag fick reda på allt annat på ett rent empiriskt sätt (det vill säga genom prövning och fel), men det visade sig skapa ett mönster.
Testexperimenten var framgångsrika. Även på arbetsbasen gick allt bra.
Så handlingssekvensen:
- utför steg 1 till 4 i den första tekniken;
- lossa utbytesfilen från UB, men ladda inte upp den till centralbanken;
- lossa utbytesfilen från centralbanken, men ladda inte upp den till UB;
- i utbytesfilen från Centralbanken ersätter vi blocket som innehåller information om konfigurationsändringar och hash (Digest1 och Digest2) med hash-blocket från UB-filen (se exempel nedan)
- vi laddar upp filen från den fjärde artikeln till UB;
- se till att skriva över utbytesfilen från UB (2: a punkten)! Denna fil ska inte laddas upp vid utbyte med centralbanken!
- för verifiering gör vi flera utbyten i följd.
Om datakomprimeringen används under utbytet stänger vi antingen av komprimeringen, eller packar först upp filen, ändrar den, packar sedan tillbaka den och skickar den.
Blockera utbytesfilen från centralbanken
... här är blocken som beskriver konfigurationsändringarna ...
måste ersättas med ett utbytesfilblock från UB (notera digest1 filen från UB är alltid lika med "0000000000000000000000000000000000" !!!)
Dessa åtgärder måste utföras med stor försiktighet, en felaktig sekvens är full av RIB: s fullständiga driftskompatibilitet. Därför, före dessa åtgärder, är att skapa säkerhetskopior MANDATORI!
För resten kan jag bara önska lycka till!
För att komma igång listar jag de förkortningar jag använder:
- RIB - distribuerad informationsbas
- Centralbank - centralbasen, RIB: s rotnod
- UB - fjärrdatabas, databas för fjärr RIB-nod
Av min egen erfarenhet kan jag säga att jag stött på två orsaker till felet:
- under mottagningen av meddelandefilen i UB "föll basen", och därför fanns det tydligen en desynkronisering mellan konf. CB och UB;
- under MSSQL laddade klienten ner en kopia av arbetsdatabasen och stängde inte av kopian i kopian. Auto-exchange-uppgifter, som ett resultat, bildades en del av meddelandena till fjärrnoderna från arbetsdatabasen, och några från kopian, vilket ledde till desync-konfigurationer
Det finns också en uppfattning om att användningen av den dynamiska databasuppdateringsmekanismen leder till detta fel. Det råder tvivel, eftersom å ena sidan påverkar dynamisk uppdatering aldrig databasstrukturen, och RIB-mekanismerna fungerar fortfarande med databasstrukturen, och inte med dess applikationsdel, ändå använder RIB mekanismen för generering av digital signatur i konfigurationsversionen (i nedan kallar jag det för att minska hash), och när applikationsdelen ändras är hash naturligtvis skyldigt att återberättas. Jag kommer varken att förneka detta eller bekräfta, för om jag stötte på den här situationen, så hittade jag inga uppenbara bevis för detta.
För korrigering använder jag två metoder beroende på situationen.
FÖRSTA METODEN
Den första (vanligaste) nämns upprepade gånger i partnerkonferensen och på andra internetresurser relaterade till 1C. Det används i de flesta fall när det, trots meddelandet om skillnader i konfigurationer, när man manuellt jämförs verkar som om de är identiska.
Sequencing:
- lossa CF-filen från centralbanken;
- vi lossar UB från RIB (SetMainHousNode-metoden, klar bearbetning finns i applikationen eller i andra publikationer);
- ersätt konf. UB till CF-filen som laddats upp i det första steget, för detta använder vi menyn "Ladda konfiguration från fil" (och inte genom jämförelse-union !!!);
- vi återställer RIB: s tecken för UB.
I de flesta fall är dessa åtgärder mer än tillräckliga för att återställa utbytet, men inte alltid ...
ANDRA METODEN
Den används om den första metoden inte fungerade och det inte går att lossa noden igen.
Bakgrund: klienten konfigurerades med en kaskad RIB och ett fel inträffade i den första nivån på kaskaden (den andra nivån fungerade perfekt hela denna tid). Utvecklingen av konfigurationen genomfördes tillsammans med kundens IT-tjänst, och eftersom felet inträffade lyckades centralbankens konfiguration ändras flera gånger. Alternativet med återföring av ändringar beaktades inte ens i princip, för förlusten av vissa data och avstängningen av flera enheter var helt oacceptabelt. Den första versionen av felkorrigeringen gav inga konkreta resultat. I det här sammanhanget var jag tvungen att leta efter andra lösningar.
Idén kom upp för att försöka ersätta hasherna för konfigurationsfilerna direkt i XML-utbytesfilerna. Beskrivningen av utbytesfilens struktur från boken "Professional Development in 1C: Enterprise 8" gav en dålig uppfattning om bildandet av digitala signaturer för konfigurationer och förändringar i dem, men bestämde riktningen för sökningen: Digest1 och Digest2-värden. Jag fick reda på allt annat på ett rent empiriskt sätt (det vill säga genom prövning och fel), men det visade sig skapa ett mönster.
Testexperimenten var framgångsrika. Även på arbetsbasen gick allt bra.
Så handlingssekvensen:
- utför steg 1 till 4 i den första tekniken;
- lossa utbytesfilen från UB, men ladda inte upp den till centralbanken;
- lossa utbytesfilen från centralbanken, men ladda inte upp den till UB;
- i utbytesfilen från Centralbanken ersätter vi blocket som innehåller information om konfigurationsändringar och hash (Digest1 och Digest2) med hash-blocket från UB-filen (se exempel nedan)
- vi laddar upp filen från den fjärde artikeln till UB;
- se till att skriva över utbytesfilen från UB (2: a punkten)! Denna fil ska inte laddas upp vid utbyte med centralbanken!
- för verifiering gör vi flera utbyten i följd.
Om datakomprimeringen används under utbytet stänger vi antingen av komprimeringen, eller packar först upp filen, ändrar den, packar sedan tillbaka den och skickar den.
Blockera utbytesfilen från centralbanken
du måste ersätta den med blocket för utbytningsfilen från UB (notera digest1 filen från UB är alltid lika med "000000000000000000000000000000000000" !!!)
Dessa åtgärder måste utföras med stor försiktighet, en felaktig sekvens är full av RIB: s fullständiga driftskompatibilitet. Därför, före dessa åtgärder, är att skapa säkerhetskopior MANDATORI!
För resten kan jag bara önska lycka till!
Fel i dynamiska uppdateringar (eller andra plattformsglitches) kan vara orsakerna till fel vid utbyte av distribuerade infobaser:
"Data tas emot från noden för vilken konfigurationsändringar registreras"
"Konfigurationen för den distribuerade IB-noden är inte som förväntat"
Hur återställer utbytet?
Men vi börjar inte med restaureringen utan med möjligheten att spendera omkring"manuellt" utbyte, vilket är viktigt under dagen, eftersom, som alltid, allt bör fungera "igår" :) Du kan göra detta med hjälp av underbara behandlingar som jag intedär jag laddade ner nakenbilder (författare, svara - jag lämnar länkar till din resurs, och från min, om det behövs - jag tar bort) Bearbetning gör det möjligt att ladda upp endast registrerade dataförändringar i databasen (enligt den angivna utbytesplanen för en specifik nod!) Till XML utan att ladda upp konfigurationsändringar och, om konfigurationsobjekt inte ändras kraftigt, det vill säga det finns mycket goda chanser att ladda dessa data. Dessa kan laddas ner från länken i slutet av artikeln.
När det gäller återhämtning. Det finns enklare metoder, inklusive inte alla punkter i listan nedan, men de hjälper inte alltid, som var fallet i ett av mina fall. Därför presenterar jag den metod som hjälpte mig, den kringgår möjliga problem på ett mer komplex sätt. Nästa steg för steg.
Det är lämpligt att ta 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 för dig själv, och därför måste du först förstå dess logik.
1. Gör säkerhetskopior överallt.
2. För klientservrar: koppla bort databasen genom "serveradministration" och anslut omedelbart till installationen av blockering av schemalagda uppgifter (detta återställer servercachen). Efter det, glöm inte att överföra registreringsloggen till den nya katalogen.
3. Ta bort databasen i listan över 1C-startbaser på alla datorer som används för återställning och skapa en ny (användarens cache kommer att rensas)
4. Lägg till en ny konstant i konfiguratorn (i den centrala databasen) för att spara ändringar i konf.
5. Rensa alla delningskataloger.
6. Gör lossning till alla grenar (hittills endast lossning).
7. Försök att ladda ner (bara ladda ner) den mottagna informationen till alla grenar. Det är naturligt att acceptera ändringar i konf.
Om allt är bra överallt, gå vidare, om allt är dåligt - vi tror att lossning av .cf från den centrala basen och nedladdning till grenen (inte en jämförelse-union) kan hjälpa. I den underordnade noden bör du koppla bort basen från RIB (bearbetning hjälper till med detta - ladda ner länken nedan). En artikel om detta ämne finns på infostart.ru.
8. Vi avbryter registreringen av förändringar för filialer i Centralbanken (vi har ju 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 in i andra grenar. (ladda ner behandlingen för kopplingslänken med länken nedan).
9. Vi gör lastningen i Centralbanken och om allt är bra, gör vi lossningen med varje filial flera gånger för att konsolidera resultatet.
10. Det är det.
Du kan aktivera schemalagda uppgifter för klientserverdatabaser.
För att förhindra problem som orsakar detta fel rekommenderas det att du inte gör en dynamisk uppdatering (åtminstone flera gånger i rad - tills ändringarna laddas upp till grenarna), och det är också tillrådligt att kontrollera kryssrutan "utbytesdata endast vid framgångsrik uppladdning".
För plattformar 1s 8.x, när ett fel inträffar, "Konfigurationen av den distribuerade IS-noden matchar inte den förväntade"
Problemlösningsteknik
Lista med förkortningar som jag använder:
RIB - distribuerad informationsbas
Centralbank - centralbasen, RIB: s rotnod
UB - fjärrdatabas, databas för fjärr RIB-nod
Av min egen erfarenhet kan jag säga att jag stött på två orsaker till felet:
under mottagandet av meddelandefilen i UB, föll basen, och därför fanns det tydligen en desynkronisering mellan konf. CB och UB;
under MSSQL laddade klienten ner en kopia av arbetsdatabasen och stängde inte av kopian i kopian. Auto-exchange-uppgifter, som ett resultat, bildades en del av meddelandena till fjärrnoderna från arbetsdatabasen, och några från kopian, vilket ledde till desync-konfigurationer
Det finns också en uppfattning om att användningen av den dynamiska databasuppdateringsmekanismen leder till detta fel. Det finns tvivel, eftersom å ena sidan påverkar dynamisk uppdatering aldrig databasstrukturen, och RIB-mekanismerna fungerar fortfarande med databasstrukturen, och inte med dess applikationsdel, ändå använder RIB mekanismen för generering av digital signatur i konfigurationsversionen (i nedan kallar jag det för att minska hash), och när applikationsdelen ändras är hash naturligtvis skyldigt att återberättas. Jag kommer varken att förneka detta eller bekräfta, för om jag stötte på den här situationen, så hittade jag inga uppenbara bevis för detta.
För korrigering använder jag två metoder beroende på situationen.
FÖRSTA METODEN
Den första (vanligaste) nämns upprepade gånger i partnerkonferensen och på andra internetresurser relaterade till 1C. Det används i de flesta fall när det, trots meddelandet om skillnader i konfigurationer, när man manuellt jämförs verkar som om de är identiska.
Sequencing:
1. Lossa CF-filen från centralbanken;
2. vi kopplar ur UB från RIB (SetMainHousNode-metoden, färdigbehandlad bearbetning finns i bilagan eller i andra publikationer);
3. byt ut konf. UB till CF-filen som laddats upp i det första steget, för detta använder vi menyn "Ladda konfiguration från fil" (och inte genom jämförelse-union !!!);
4. vi återställer RIB: s tecken för UB.
I de flesta fall är dessa åtgärder mer än tillräckliga för att återställa utbytet, men inte alltid ...
ANDRA METODEN
Den används om den första metoden inte fungerade och det inte går att lossa noden igen.
Så handlingssekvensen:
1. utför steg 1 till 4 i den första tekniken;
2. Lossa utbytesfilen från UB, men ladda inte upp den till centralbanken.
3. lossa utbytesfilen från centralbanken, men ladda inte upp den till UB;
4. i utbytesfilen från centralbanken ersätter vi blocket som innehåller information om konfigurationsändringar och hash (Digest1 och Digest2) med hash-blocket från UB-filen (se exempel nedan)
5. vi laddar upp filen från den fjärde artikeln till UB;
se till att skriva över utbytesfilen från UB (2: a punkten)! Denna fil ska inte laddas upp vid utbyte med centralbanken!
för verifiering gör vi flera utbyten i följd.
Om datakomprimeringen används under utbytet stänger vi antingen av komprimeringen, eller packar först upp filen, ändrar den, packar sedan tillbaka den och skickar den.
Blockera utbytesfilen från centralbanken
måste ersättas med ett utbytesfilblock från UB (notera Digest1 filen från UB är alltid “000000000000000000000000000000000000” !!!)
Dessa åtgärder måste utföras med stor försiktighet, en felaktig sekvens är full av RIB: s fullständiga driftskompatibilitet. Därför, före dessa åtgärder, är att skapa säkerhetskopior MANDATORI!
