#Backup

Es posible que hayáis notado que, para configurar un mirror en InterSystems IRIS for Health™ y HealthShare® Health Connect, hay un requisito especial. En este artículo, quiero guiaros paso a paso por el proceso.

Esto supone que ya habéis configurado el segundo miembro de conmutación por error y habéis confirmado un estado exitoso de dicho miembro en el monitor del mirror:

Paso 1: Activad el usuario HS_Services (en el servidor de respaldo y en el principal).

Paso 2: Cambiad al espacio de nombres HSSYS y dirigíos a Interoperabilidad > Configurar > Credenciales.

Hola comunidad.

Hemos desarrollado una nueva versión de una producción, todo el código es nuevo y ha cambiado BP. Esta aplicación carga información para algunas marcas y la almacena en la base de datos.

El cliente quiere implementar los cambios solo para algunas marcas porque quiere verificar las marcas pequeñas antes de implementarlos para todas las marcas.

Mi propuesta es crear un nuevo namespace, con el nuevo código, y deshabilitar todas las marcas excepto la marca que quiere probar.

Me pregunto cuál es la mejor manera de clonar el namespace.

Mi primer intento es hacer una copia de las bases de

En este artículo, crearemos una configuración de IRIS con alta disponibilidad utilizando implementaciones en Kubernetes con almacenamiento persistente distribuido en vez del "tradicional" par de mirror de IRIS. Esta implementación sería capaz de tolerar fallos relacionados con la infraestructura, por ejemplo, fallos en los nodos, en el almacenamiento y en la Zona de Disponibilidad. El enfoque descrito reduce en gran medida la complejidad de la implementación, a costa de un Tiempo Objetivo de Recuperación (RTO, Recovery Time Objective) ligeramente mayor.

Todo el código fuente del artículo está disponible en: https://github.com/antonum/ha-iris-k8s 

En el artículo anterior, comentamos cómo configurar IRIS en el clúster k8s con alta disponibilidad, basado en el almacenamiento distribuido, en vez del mirroring tradicional.Como ejemplo, ese artículo utilizaba el clúster Azure AKS.En esta ocasión, seguiremos explorando las configuraciones de alta disponibilidad en los k8s.

Trabajando en soporte generalmente me preguntan cuántos días hay que mantener los journals. ¿Debería ser dos días o después de dos copias de seguridad? ¿Más? ¿Menos? ¿Por qué dos?

La respuesta correcta (para la mayoría de los entornos) es que se debería conservar los ficheros de journal desde la última copia de seguridad validada. Es decir, hasta que no verifique si una copia de seguridad es válida (restaurando el archivo y verificándolo con la utilidad Integrity), no puede estar seguro de que haya una buena copia de los datos y no por tanto no se deberían purgar los journals de manera segura.

Hola a todos.

Me encontré con algunos problemas cuando configuré los scripts por lotes de freeze/thaw para usarlos con VMWare en un ecosistema de Windows, y quería compartir lo que encontré por si pudiera ayudar a otros. Esto se llevó a cabo en un entorno que utiliza HealthConnect 2019.1.x.

IRIS no se ejecutó (2)

Parece que el script de ejemplo de la documentación, en mi caso, me indicaba que el entorno no se estaba ejecutando (a pesar de que se estaba ejecutando). Para corregir esto, proporcioné la ruta de acceso a la ubicación de Mgr, de la siguiente forma:

c:\InterSystems\HealthConnect\bin\iris

Aunque la integridad de las bases de datos Caché e InterSystems IRIS está completamente protegida de las consecuencias de un fallo de sistema, los dispositivos de almacenamiento físico sí que pueden fallar, corrompiendo los datos que almacenan.

Por esa razón, muchos sitios optan por realizar chequeos o verificaciones periódicas de integridad de bases de datos, sobre todo en coordinación con las copias de seguridad, para validar que se pueda confiar en una determinada copia de seguridad en caso de que ocurra algún desastre.

Esta publicación es la traducción de un artículo que publicó mi compañero Murray hace un tiempo. Durante mi trabajo en soporte la he recomendado muchas veces, pues lo que aquí se explica es bastante común y los ejemplos que se dan pueden ayudar a muchos de vosotros.

En esta publicación muestro estrategias para realizar copias de seguridad de Caché utilizando un Backup externo, con ejemplos de integración con soluciones basadas en snapshots. La mayoría de soluciones que veo hoy en día se implementan en Linux con VMware, por lo que gran parte de este artículo muestra, como ejemplos, cómo las

Los sistemas de bases de datos tienen requisitos muy específicos para las copias de seguridad ("backups") que, en entornos empresariales, necesitan una previsión y planificación. En el caso de los sistemas de bases de datos, el objetivo de una copia de seguridad es crear una copia de los datos en un estado equivalente a cuando la aplicación se apaga de forma correcta. Las copias de seguridad consistentes con las aplicaciones cumplen estos requisitos, y Caché ofrece un conjunto de APIs que facilitan la integración con soluciones externas para lograr este nivel de consistencia en las copias de seguridad.

Saludos comunidad. Me gustaría saber cómo migrar un BD en producción a un entorno local. Cuando tengo un sistema en producción (Servidor BD Sql), lo que hacemos es montar una copia local para hacer el análisis con los datos y no ocupar los recursos del sistema en producción. Mi pregunta es: ¿cómo se hace con la tecnología Intersystems? Ya probé el conector PowerBi y se ve muy bien, pero ahí es donde surgió la pregunta.