La configuración de IB distribuida no es la esperada. Para evitar problemas que causen este error, se recomienda no realizar una actualización dinámica (al menos varias veces seguidas, antes de descargar los cambios en las sucursales), y también preferiblemente en la configuración

¡Hola, queridos lectores de nuestro sitio de blog! hoy hablaremos de
arreglando dos errores que puedan surgir durante el intercambio en una base de datos distribuida (DIB). Dichos errores pueden ocurrir si ha cambiado la configuración de su base de datos y está tratando de transferir estos cambios desde la base de datos central a la remota. Por ejemplo, en la forma en que se describió. ¡Empecemos!

Estos son los mensajes que pueden aparecer al intentar realizar un intercambio mediante RIB:

“Se reciben datos del nodo para el cual
cambios de configuración registrados.
Los cambios deben migrarse
configuración al nodo".

“Configuración del nodo IS distribuido
¡no como se esperaba!

Veamos los pasos para ayudar a solucionar la situación. Antes de empezar, hagamos nuestras bases de información!!!

Cogemos el archivo de configuración con la actualización, abrimos la base de datos central en el Configurador y lo cargamos (Configuración-Cargar configuración desde archivo...). Guardar IB (F7).
Vamos a y subimos a un archivo para la base de periféricos:
- Seleccione el plan de intercambio en la lista, luego haga clic derecho para abrir el menú contextual y seleccione el elemento "Escribir cambios...".
Ahora echemos un vistazo a la seguridad de la información periférica. Vamos a abrirlo en modo exclusivo para que no haya usuarios, y cerramos también el Configurador. Ahora debe recordar el nodo que es el principal para la base actual. Abra Operaciones-Planes de cambio-Seleccione su plan de cambio (por ejemplo, "Por almacén"). En la lista de planes de intercambio, el nodo maestro es el elemento con el icono amarillo. Esta información nos será de utilidad en el séptimo párrafo. Abra el procesamiento y haga clic en el botón "Desasignar el nodo maestro".
Ahora abramos la IB del periférico en el Configurador y carguemos el mismo archivo de configuración que cargamos en el primer paso en la base de datos central (Configuración-Cargar configuración desde archivo...). Guardar IB (F7).
Vamos a cambiar la configuración de soporte (Configuración-Soporte-Configuración de soporte...). En el cuadro de diálogo, seleccione una celda de la tabla en la intersección de la primera fila y la segunda columna. Luego, al hacer doble clic, llamaremos al cuadro de diálogo "Configuración de reglas de soporte". En él, marque la bandera "Instalar para objetos subordinados" y haga clic en el botón "Aceptar". Cierre el cuadro de diálogo de configuración de soporte haciendo clic en el botón "Cerrar". Guardar IB (F7). Cerremos el Configurador.
Ahora abriremos de nuevo el IS periférico en el modo exclusivo 1C:Enterprise para que no haya usuarios, y cerraremos también el Configurador. Abramos el procesamiento InstallMainNodeDB.epf y seleccionemos el plan de intercambio que queremos establecer como nodo principal (en el cuarto párrafo recordamos este nodo). Luego haga clic en el botón "Instalar nodo maestro". Después de eso, el IB actual volverá a ser periférico.
Ahora, en el IB actual (periférico), abra los planes de intercambio y descargue el archivo con el intercambio de la Base de Datos Central, que recibimos en el tercer paso:
- Operaciones-Planes de cambio-Seleccione nuestro plan de cambio (por ejemplo, "Por almacén").
Si todo salió bien, descargaremos el intercambio para la base de datos Central en el IB actual (periférico):
- Operaciones-Planes de cambio-Seleccione nuestro plan de cambio (por ejemplo, "Por almacén").
- Seleccione el plan de intercambio en la lista, luego haga clic derecho para abrir el menú contextual y seleccione el elemento "Escribir cambios...".
- En el cuadro de diálogo, especifique la ruta y el nombre del archivo de intercambio. Presionamos el botón "OK".
Ahora intentemos cargar este archivo en la base de datos central, ábralo en 1C: modo Enterprise:
- Operaciones-Planes de cambio-Seleccione nuestro plan de cambio (por ejemplo, "Por almacén").
- Seleccione el plan de intercambio en la lista: haga clic con el botón derecho para abrir el menú contextual y seleccione "Leer cambios..."
- En el cuadro de diálogo, seleccione el archivo de intercambio. Presionamos el botón "OK".

Para evitar problemas con las copias de trabajo, primero haga

A menudo se utiliza una base de información distribuida (DIB) para organizar el trabajo de las sucursales y divisiones, lo que le permite intercambiar información rápidamente manteniendo el grado de autonomía deseado. Sin embargo esta tecnología lo suficientemente confiable, se rompe de vez en cuando. Hoy veremos uno de los errores bastante comunes: hablemos sobre las causas de su aparición y los métodos para tratarlo.

Comencemos, como siempre, desde el principio. Después de haber creado la RIB, todos los cambios en la configuración base de información solo se puede ingresar en el nodo principal. Posteriormente, en el próximo intercambio, todos los cambios se transferirán a los nodos esclavos y se aplicarán allí automáticamente. Pero fue suave en el papel...

En la práctica, a veces sucede que entre sesiones de intercambio, especialmente si el canal es malo en la periferia, la configuración del nodo principal tiene tiempo de cambiar dos veces. Por ejemplo, hicieron cambios, los subieron, la base de periféricos recibió los cambios, pero aún no los ha aplicado, lo que puede llevar algún tiempo, y aún no ha enviado la confirmación. Si vuelve a realizar cambios en este intervalo y vuelve a descargar el intercambio, resulta que el centro espera ver la configuración No. 1 en el nodo periférico e intenta actualizarlo a la configuración No. 3, pero en realidad se encontrará con la configuración No. .2 allí. A veces ocurre una situación similar cuando la base de datos central se actualiza dinámicamente. Como resultado, el intercambio será imposible y recibirá un mensaje que indica que ¡La configuración del nodo IS distribuido no es la esperada!

En general, la moraleja de esta historia es simple: no refine activamente la base de trabajo y, si lo hace, finalice todas las sesiones de intercambio antes de realizar los siguientes cambios. Pero, ¿y si tal molestia todavía ocurriera?

La solución de fuerza bruta es crear una nueva imagen del nodo esclavo, pero en la práctica no suele ser aplicable. Por regla general, la aparición de un error grave durante el intercambio no se soluciona inmediatamente, sino algún tiempo después de que los datos operativos de las bases periféricas hayan dejado de llegar. Según el cronograma de intercambio, puede tomar un día hábil completo o más entre el momento en que ocurre un problema y cuando se descubre.

Aquí vale tirar una piedra al jardín del desarrollador, que lo emite como un error y resalta la situación en rojo de la misma manera. El número de mensaje es menor o igual que el número de mensaje recibido anteriormente. que en general es bastante normal. Como resultado, la percepción de los errores por parte de los usuarios se embota y simplemente dejan de leer los mensajes mostrados, creyendo que todo está bien y que la otra parte aún no ha hecho un intercambio en casa.

Pero volvamos a nuestro error. La solución es bastante simple y está en la superficie: lleve la configuración de la base periférica a la esperada, es decir. adecuarlo a la configuración del nodo central. Pero en la práctica, esto no es tan fácil de hacer. Si abrimos la base de datos de periféricos en el configurador, veremos que los cambios están bloqueados por las herramientas de gestión de RIB.

Para cambiar la configuración de un nodo esclavo, deberá desconectarlo temporalmente de la base central. A estos efectos, puede utilizar alguno de los tratamientos que se encuentren suficientemente representados en la red, o desactivar la seguridad de la información desde el nodo central usando el parámetro de lanzamiento del Configurador/ResetMasterNode.

Abra un símbolo del sistema y escriba (teniendo en cuenta la versión de la plataforma y la ruta de instalación real):

"C:\Archivos de programa (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNode

Después de ejecutar este comando, aparecerá la ventana de inicio habitual, seleccione la base deseada allí y haga clic en el botón Configurador.

Lanzamiento de IB al mismo tiempo No pasará, es decir. puede parecer que no ha pasado nada, pero al abrir la base de datos nuevamente en el Configurador, puede asegurarse de que esté desconectada del nodo principal y disponible para realizar cambios.

¡Atención! En las plataformas 8.3.7 - 8.3.9, este comando fallará. El error se ha corregido en la plataforma 8.3.10.

Si no quieres meterte con línea de comando, entonces puede usar uno de los procesamientos, a continuación se muestra el que usamos, se encontró en Internet y solo le hicimos cambios cosméticos. Tenga en cuenta que el procesamiento solo es adecuado para una aplicación normal; para configuraciones en una aplicación administrada, use la tecla de inicio del Configurador.

Trabajar con él es extremadamente simple, lo lanzamos en 1C: modo Enterprise, a través de Archivo - Abrir, luego simplemente presione el botón deseado, en nuestro caso Deshabilitar nodo maestro.

Ahora necesitamos la configuración real del nodo central. Para ello, abra SI central en el Configurador y ejecutar Configuración: guardar la configuración en un archivo. El archivo resultante con la extensión cf deben enviarse al nodo periférico.

Luego, en el nodo periférico, lanzamos el IS (habiéndolo desconectado previamente del nodo principal) en el Configurador y lo retiramos del soporte. Para hacer esto, elija: Configuración - Soporte - Configuración de soporte.

En la ventana que se abre, primero habilite las opciones de cambio.

Y luego eliminamos la configuración del soporte.

Ahora puede cargar la configuración desde un archivo, para ello, seleccione Configuración - Cargar configuración desde archivo y especificar no pasado desde el nodo central cf-Archivo. Después de eso, recibirá una advertencia de que la configuración actual no está vacía. Tenga en cuenta que las manipulaciones que realizamos son potencialmente peligrosas y pueden causar daños irreversibles a IS, por lo tanto, antes de continuar, asegúrese de tener una copia de seguridad actualizada.

El archivo con el mensaje ya se cargó en la base receptora. Es necesario descargarlo de la base de datos de origen nuevamente.

Error "Se produjo un error al copiar un archivo desde un recurso FTP... Error al trabajar con Internet: se alcanzó el tiempo de espera"

Desde el sitio a través del cual pasa el intercambio, es imposible copiar archivo deseado. Esto puede deberse a trabajo lento tu Internet o con los problemas del propio sitio.
Debe intentar repetir el intercambio en 15-30 minutos.

Error "Está prohibido editar los datos de este período. Los cambios no se pueden registrar…”

Los datos cargados contienen documentos de un período cerrado.
Es necesario realizar un intercambio bajo los usuarios que tienen derecho a cambiar documentos en este período.

Error "Necesita realizar actualizaciones de configuración de la base de datos. La actualización se puede hacer en el modo configurador"

Motivo: Los programadores cambiaron la configuración en el centro. Solución: Actualice la configuración modificada en la base del borde. Para esto:

Ir al configurador.
Ejecute el elemento de menú "Configurador / Actualizar configuración de la base de datos".
Si una pregunta se muestra con respuestas solo "Repetir", "Cancelar", "Actualizar dinámicamente", haga clic en el botón "Actualizar dinámicamente".
Si se emite una pregunta con respuestas solo "Reintentar" y "Cancelar".
- todos los usuarios para salir 1C.
- presione el botón "Repetir".
Responda afirmativamente al resto de preguntas: “Sí”, “Acepto”, “OK”.
Cierra el configurador.
Vuelva a intentar la descarga desde el centro.

Error "La configuración no coincide con lo esperado", "Intentando aceptar cambios de una configuración desconocida"

Error de la base de datos.
Tienes que contactar con los expertos.

Para empezar, aquí hay una lista de las abreviaturas que uso:

RIB - base de información distribuida
CB - base central, nodo raíz RIB
UB - base remota, base de datos del nodo remoto RIB

Por experiencia propia Puedo decir que encontré dos razones para el error:

mientras recibía el archivo del mensaje en la UB, la base "cayó", en relación con lo cual, aparentemente, hubo una desincronización entre el conf. Banco Central y UB;
bajo MSSQL, el cliente cargó una copia de la base de datos de trabajo y no la apagó en la copia del registro. tareas de intercambio automático, como resultado, algunos mensajes en nodos remotos se formó a partir de la base de datos de trabajo y parte de la copia, lo que condujo a la desincronización de las configuraciones

También existe la opinión de que el uso del mecanismo de actualización dinámica de la base de datos conduce a este error. Aquí hay dudas, porque por un lado actualización dinámica nunca afecta la estructura de la base de datos, y los mecanismos RIB todavía funcionan con la estructura de la base de datos, y no con su parte de aplicación, sin embargo, el RIB usa el mecanismo para generar una firma digital de la versión de configuración (en adelante lo llamaré un hash para abreviar ), y al cambiar la parte de la aplicación, el hash naturalmente debe volver a calcularse. No negaré esto, ni lo afirmaré, porque. si me enfrenté a esta situación, entonces no encontré evidencia clara de esto.

Utilizo 2 métodos para arreglarlo, dependiendo de la situación.

PRIMER MÉTODO

El primero (el más común) se menciona repetidamente tanto en la conferencia de socios como en otros recursos de Internet relacionados con 1C. Se utiliza en la mayoría de los casos, cuando a pesar del mensaje sobre las discrepancias de las configuraciones, al compararlas manualmente, parece que son idénticas.

Secuenciación:

descargar el archivo cf del Banco Central;
desvinculamos la UB de la RIB (el método SetMainNode, el procesamiento listo para usar se puede encontrar en la aplicación o en otras publicaciones);
reemplazar conf. UB en el archivo cf descargado en el primer paso, para esto usamos el menú "Cargar configuración desde archivo" (¡¡y no por comparación-unión !!!);
restablezcamos el signo de RIB para UB.

En la mayoría de los casos, estas acciones son más que suficientes para restaurar el intercambio, pero no siempre...

SEGUNDO MÉTODO

Se usa si el primer método no funcionó y no es posible descargar el nodo nuevamente.

Antecedentes: el cliente estaba configurando una RIB en cascada y ocurrió un error en el primer nivel de la cascada (el segundo nivel funcionó sin problemas todo este tiempo). La configuración fue desarrollada en conjunto con el servicio de TI del cliente, y desde que ocurrió el error, la configuración del CB ha cambiado varias veces. La opción de revertir los cambios ni siquiera se consideró en principio, porque la pérdida de parte de los datos y el cierre de varios departamentos fueron completamente inaceptables. La primera versión de la corrección de errores no dio ningún resultado tangible. Como resultado, hubo que encontrar otras soluciones.

La idea surgió de intentar cambiar los hashes de los archivos de configuración directamente en los archivos XML de intercambio. La descripción de la estructura del archivo de intercambio del libro "Desarrollo profesional en el sistema 1C: Enterprise 8" dio una mala idea de la formación. firmas digitales configuraciones y cambios en ellas, pero determinó la dirección de búsqueda: valores Digest1 y Digest2. Descubrí todo lo demás de manera puramente empírica (es decir, por ensayo y error), pero logré establecer un patrón.

Los experimentos de prueba fueron bien. En las bases, también, todo salió bien.

Entonces, la secuencia de acciones:

realice los pasos 1 - 4 de la primera técnica;
descargar el archivo de intercambio de la UB, pero no subirlo a la CB;
descargar el fichero de cambio del Banco Central, pero no subirlo a la UB;
en el archivo de intercambio del CB, reemplazamos el bloque que contiene información sobre cambios de configuración y hash (Digest1 y Digest2) con un bloque de hash del archivo UB (ver un ejemplo a continuación)
subimos el archivo del punto 4 a la UB;
¡asegúrese de sobrescribir el archivo de intercambio de la UB (segundo párrafo)! ¡este archivo no debe cargarse al intercambiar en el CB!
para comprobar, hacemos varios intercambios consecutivos.

Si se utiliza la compresión de datos durante el intercambio, desactive la compresión o primero descomprima el archivo, cámbielo, luego vuelva a empaquetarlo y envíelo.

Intercambio de archivos de bloque de CB

106.0...aquí hay bloques que describen los cambios de configuración... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

necesita ser reemplazado con un bloque del archivo de intercambio de la UB (tenga en cuenta que el Digest1 del archivo de la UB siempre es igual a "000000000000000000000000000000000"!!)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

Las acciones enumeradas deben realizarse con extrema precaución, una secuencia incorrecta conlleva la inoperancia total de la RIB. Por lo tanto, ante estas acciones, la creación copias de seguridad¡NECESARIAMENTE!

De lo contrario, ¡solo puedo desearte buena suerte!