En este capítulo, se describe en detalle la administración de los diferentes servicios de STA. Para la configuración inicial de estos servicios, consulte Guía de instalación y configuración de STA.
En este capítulo, se incluyen las siguientes secciones:
El daemon de servicios de STA, staservd, es un servicio de Linux que se ejecuta de manera continua y es responsable de la gestión y la ejecución del servicio de copias de seguridad de STA y el servicio de supervisión de recursos de STA. Tanto el servicio de copia de seguridad de STA como el servicio de supervisión de recursos de STA se ejecutan como threads de ejecución independientes en el daemon de servicios de STA.
El daemon de servicios de STA se inicia cuando el servidor de STA se inicia (con el comando STA start all) y termina cuando se apaga el servidor. También puede iniciar, detener y controlar el estado del daemon de servicios de STA con los siguientes comandos:
Para iniciar el daemon de servicios de STA:
# STA start staservd
Starting staservd Service...
staservd service was successfully started
Para detener el daemon de servicios de STA:
# STA stop staservd
Stopping the staservd Service...
Successfully stopped staservd service
Para comprobar el estado del daemon de servicios de STA:
# STA status staservd
staservd service is running
Para obtener más información acerca del comando STA, consulte el Capítulo 1, Administración del servidor..
Nota:
Después de la instalación de STA, el daemon de servicios de STA inicia los servicios de copia de seguridad y supervisión de recursos de STA, pero estos no se activarán hasta que se los configure. Para configurar estos servicios, consulte la Guía de instalación y configuración de STA.El servicio de copia de seguridad de STA es uno de varios servicios que se ejecutan en el daemon de servicios de STA. Realiza una copia de seguridad completa automática de la base de datos y los directorios de configuración clave de STA y escribe los archivos en una ubicación especificada del servidor de STA o en forma comprimida en un servidor remoto. Oracle recomienda configurar un servidor de copia de seguridad remoto.
Antes de continuar, verifique que el daemon de servicios de STA se esté ejecutando. Consulte la Daemon de servicios de STA.
Visualización de la configuración de preferencias del servicio de copia de seguridad
Verificación del envío de archivos de copia de seguridad al servidor de destino
Restablecimiento de la contraseña del servicio de copia de seguridad de STA
El servicio de copia de seguridad de STA se configura mediante la utilidad de administración, staservadm, que se encuentra en /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin. Para configurar el servicio de copia de seguridad de STA, consulte la Guía de instalación y configuración de STA.
Una vez configurado, el servicio de copia de seguridad de STA lleva a cabo el siguiente proceso una vez cada 24 horas:
Inicia un volcado de alta velocidad (también denominado copia de seguridad en caliente) de los siguientes tipos de archivo:
Archivo de volcado de base de datos MySQL
Archivos de log binarios de MySQL
Archivos de configuración del daemon de servicios de STA y WebLogic de STA
Logs de administración del daemon de servicios de STA y el servicio de copia de seguridad de STA
Transfiere el archivo de volcado al host de copia de seguridad designado
Suprime del servidor de STA los archivos de volcado completo del día anterior
Escribe una copia de los archivos de volcado del día en curso en el directorio /sta_db_backup/local del servidor de STA.
Visualice el estado de la configuración actual de preferencias.
# ./staservadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Backup Service Settings: Configured [yes] File Transfer –S [SCP] Full Backup –T [11:00] Sleep Interval –i [350 sec] Backup Hostname –s [stabaksvr] Backup Username –u [stabck] Backup Password –p [*******] Backup Directory –d [/home/stabck/STAbackups] Database Username –U [stadba] Database Password –P [*********]
Si el campo Configured (Configurado) dice [no], significa que el servicio de copia de seguridad se está ejecutando en el modo inactivo y no está realizando ninguna copia de seguridad. Debe proporcionar los valores de configuración adecuados; consulte información detallada en Guía de instalación y configuración de STA.
Borre la configuración actual de preferencias.
# ./staservadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Backup Service Settings: Configured [no] File Transfer –S [SCP] Full Backup –T [00:00] Sleep Interval –i [300 sec] Backup Hostname –s [] Backup Username –u [] Backup Password –p [] Backup Directory –d [] Database Username –U [] Database Password –P []
El servicio de copia de seguridad ya no está configurado y regresa al estado inactivo. Ahora puede proporcionar nuevos valores de configuración; consulte la información detallada en la Guía de instalación y configuración de STA.
Para verificar que los archivos se hayan enviado correctamente al servidor de destino:
Compruebe los logs del servidor de STA.
Inicie sesión en el servidor de copia de seguridad de destino y muestre el contenido del directorio de copia de seguridad.
Inicie sesión en el servidor de STA como usuario root del sistema.
Cambie al directorio de log de copia de seguridad de la base de datos de STA.
# cd /sta_logs/db/backups
Busque la siguiente cadena en el archivo staservd.log.0: "INFO: done. Database dump completed.". Este archivo registra las actividades de la utilidad de configuración de los servicios de copia de seguridad.
# grep "INFO: done. Database dump completed" staservd.log.0
INFO: done. Database dump completed, file located at /dbbackup/local/20130721_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130722_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130723_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130724_133755.stafullbackup.sql
Inicie sesión en el servidor de copia de seguridad de destino.
Muestre una lista de los archivos que se encuentran en el directorio de copias de seguridad de bases de datos.
En este ejemplo, el directorio /backups/tbivb01 fue configurado previamente para recibir los archivos de copia de seguridad del servidor de STA ”tbivb01”.
# ls –1 /backups/tbivb01
0.stadb-bin.000023.gz 0.stadb-bin.000024.gz 0.stadb-bin.000026.gz 0.stadb-bin.000027.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000025.gz 20130723_133755.stadb-bin.000026.gz 20130723_133755.stafullbackup.sql.gz
Para verificar que se haya guardado una copia de los archivos de la copia de seguridad más reciente de manera local en el servidor de STA, muestre una lista de los archivos del directorio /sta_db_backup/local. Por ejemplo:
# ls –l /dbbackup/local
20130721_133755.conf.zip 20130721_133755.fmwconfig.zip 20130721_133755.stafullbackup.zip
Los archivos mostrados tienen el formato AAAAMMDD_HHMMSS.nombre de archivo.zip.
Consulte el Capítulo 3, Administración de contraseñas.
El servicio de supervisión de recursos de STA supervisa los recursos del servidor de STA, incluidos el espacio de tablas de la base de datos y el espacio de volumen de disco, el espacio de disco de volumen de log y el uso de memoria física, y genera los informes correspondientes.
Es posible configurar límites superiores (HWM) de uso para cada recurso. Un límite superior es un umbral que, cuando se lo alcanza, hace que se genere una alerta. Cuando se alcanza o se excede este umbral, se registra una alerta en el informe de recursos diario estándar y, de manera opcional, se la envía por correo electrónico a uno o varios destinatarios designados.
Por ejemplo, si el espacio de tablas de la base de datos tiene un HWM del 60%, cuando el supervisor de recursos de STA detecta que la aplicación de STA ha utilizado el 60% o más del espacio de tablas de base de datos máximo permitido, activa la alerta de espacio de tablas y envía un correo electrónico a los destinatarios designados. Asimismo, si el modo de insistencia está activado, el supervisor de recursos continúa enviando alertas por correo electrónico cada vez que analiza el sistema.
Consulta de la configuración de preferencias actual del supervisor de recursos
Borrado de la configuración de preferencias del supervisor de recursos
Restablecimiento de la contraseña del servicio de supervisión de recursos de STA
El servicio de supervisión de recursos de STA se configura mediante la utilidad de administración, staresmonadm, que se encuentra en /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin. Para configurar el servicio de supervisión de recursos de STA, consulte la Guía de instalación y configuración de STA.
Introduzca el siguiente comando para consultar el estado de la configuración de las preferencias:
# ./staresmonadm –Q
Si el campo Configured (Configurado) dice "no" significa que el servicio de supervisión de recursos se está ejecutando en el modo "inactivo" y no está supervisando los recursos ni enviando informes. Deberá configurar el servidor; consulte información detallada en la Guía de instalación y configuración de STA.
Ejemplo de salida de un servicio de supervisión de recursos de STA configurado:
# ./staresmonadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Resource Monitor Service Settings: Configured [yes] Send Reports –T [13:00] Sleep Interval –i [600 sec] Alert Nagging –n [on] DB Username –U [sta_dba] DB Password –P [*********] DB Tablespace hwm –t [65%] DB Backup hwm (/dbbackup) –b [65%] DB Data hwm (/dbdata) –d [65%] Log Volume hwm (/var/log/tbi) –l [65%] Root Volume hwm (/) –z [70%] Tmp Volume hwm (/tmp) –x [80%] System Memory hwm –m [75%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [john.doe@company.com] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
Introduzca el siguiente comando para borrar la configuración actual de las preferencias:
# ./staresmonadm –C
El servicio de supervisión de recursos ya no está configurado y regresa al estado inactivo. Ahora puede proporcionar nuevos valores de configuración; consulte la información detallada en la Guía de instalación y configuración de STA. Por ejemplo:
# ./staresmonadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Resource Monitor Service Settings: Configured [no] Send Reports –T [00:00] Sleep Interval –i [300 sec] Alert Nagging –n [off] DB Username –U [] DB Password –P [] DB Tablespace hwm –t [–1%] DB Backup hwm (/dbbackup) –b [–1%] DB Data hwm (/dbdata) –d [–1%] Log Volume hwm (/var/log/tbi) –l [–1%] Root Volume hwm (/) –z [–1%] Tmp Volume hwm (/tmp) –x [–1%] System Memory hwm –m [–1%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
Consulte el Capítulo 3, Administración de contraseñas.
Los informes del supervisor de recursos se configuran mediante la utilidad de administración del servicio de supervisión de recursos de STA, staresmonadm. Para configurar el servicio de supervisión de recursos de STA, consulte la Guía de instalación y configuración de STA.
El supervisor de recursos puede producir dos tipos diferentes de informes:
El informe estándar de supervisión de recursos se envía una vez por día aproximadamente a la hora especificada mediante la opción staresmonadm –T. Si no se configura ninguna hora, el informe se envía al hacer el primer análisis después de la medianoche. El informe se envía a los destinatarios de correo electrónico especificados al configurar este servicio.
El informe proporciona datos sobre los siguientes recursos del servidor. Si alguno de estos recursos excede el umbral de límite superior, aparece una alerta en el informe.
Espacio de tablas y volumen de base de datos
Volumen de log, copia de seguridad y raíz
Directorio temporal
Uso de memoria del sistema
Nota:
Los valores informados se basan en puntos de montaje. Si varios de los elementos supervisados usan el mismo punto de montaje, los valores informados para esos elementos serán idénticos.Ejemplo 2-1 Ejemplo de informe estándar (truncado)
STA RESOURCE MONITOR STANDARD REPORT System: tbivb03 Scanned: 2013-10-24 11:30:14 Database Tablespace HWM : 60.00% Used : <0.1% MB Used : 13 MB Free : 75763 MB Total : 75776 Location : /dbdata/mysql Database Volume HWM : 60.00% Used : 6.80% MB Used : 6855 MB Free : 93939 MB Total : 100794 Directory : /dbdata/mysql ...
Después de cada análisis se envía un informe de alerta de agotamiento de recursos si la opción staresmonadm alert nag mode (–n) está configurada con el valor "on". Si el modo de insistencia no está activado, las alertas se muestran solamente en el informe estándar.
El intervalo entre análisis está determinado por el atributo Sleep Interval (Intervalo de inactividad) (–i), y el informe se envía a los destinatarios de correo electrónico especificados al configurar el servicio. En el informe, se proporcionan recomendaciones para ayudar a resolver los problemas indicados.
Ejemplo 2-2 Ejemplo de informe de alerta de agotamiento de recursos
STA RESOURCE DEPLETION REPORT
System: server01
Scanned: 2013-10-24 11:34:47
************************************************************
* A L E R T S *
************************************************************
==================================================
ALERT – Low System Physical Memory
==================================================
Physical memory usage has exceeded threshold value!
HWM [1.00%]
Used [48.24%] (!)
MB Used [7757]
MB Free [8324]
MB Total [16080]
Hostname [server01]
Recommendations:
1) Shutdown unneeded processes.
2) Under Linux, try releasing unused caches using commands:
# free –m
# sync
# /sbin/sysctl –q vm.drop_caches=3
# free –m
3) Install additional memory.
Los servicios de STA están compuestos por secuencias de comandos ejecutables, archivos Java jar que contienen aplicaciones de servidor y cliente, archivos de configuración, archivos de volcado, archivos log y un archivo de datos acumulados. En esta sección, se describen sus finalidades y ubicaciones.
La secuencia de comandos de inicio y cierre del daemon de servicios de STA, staservd, y los enlaces simbólicos de nivel de ejecución del sistema se encuentran en los siguientes directorios. La secuencia de comandos y los enlaces simbólicos asociados son creados por el instalador de STA.
/etc/init.d/staservd: secuencia de comandos principal de inicio y cierre
/etc/rc0.d/K04staservd: enlace simbólico para cierre del sistema
/etc/rc1.d/K04staservd: enlace simbólico para cierre del sistema
/etc/rc2.d/S96staservd: enlace simbólico para inicio del sistema
/etc/rc3.d/S96staservd: enlace simbólico para inicio del sistema
/etc/rc4.d/S96staservd: enlace simbólico para inicio del sistema
/etc/rc5.d/S96staservd: enlace simbólico para inicio del sistema
/etc/rc6.d/K04staservd: enlace simbólico para cierre del sistema
La utilidad de administración del servicio de copia de seguridad de STA, staservadm, es una secuencia de comandos Perl que llama a una aplicación cliente Java llamada ServerAdm que está incluida en el archivo oracle.tbi.serveradm.jar. Para obtener más información, consulte la Servicio de copia de seguridad de STA.
La utilidad de administración del servicio de supervisión de recursos de STA, staresmonadm, es una secuencia de comandos Perl que llama a una aplicación cliente Java llamada StaResMonAdm que está incluida en el archivo oracle.tbi.resmonadm.jar. StaResMonAdm es un cliente de RMI que se comunica con el daemon de servicios de STA para configurar y restablecer las preferencias del tiempo de ejecución. Para obtener más información, consulte la Servicio de supervisión de recursos de STA.
En la Tabla 2-1 se muestran los programas ejecutables y sus ubicaciones.
Tabla 2-1 Ubicaciones de programas ejecutables
| Programa | Ubicación |
|---|---|
|
Archivo jar de programa de servicios de STA |
$STAHOME/common/lib/oracle.tbi.server.jar |
|
Archivo jar de aplicación Java de utilidad de administración de servicios de copia de seguridad de STA |
$STAHOME/common/lib/oracle.tbi.serveradm.jar |
|
Archivo de secuencia de comandos de usuario de utilidad de administración de servicios de copia de seguridad de STA, staservadm |
$STAHOME/common/bin/staservadm |
|
Archivo jar de aplicación Java de utilidad de administración de servicios de supervisión de recursos de STA |
$STAHOME/common/lib/oracle.tbi.resmonadm.jar |
|
Archivo de secuencia de comandos de usuario de Java de utilidad de administración de supervisión de recursos de STA, staresmonadm |
$STAHOME/common/bin/staresmonadm |
Donde:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
La copia de seguridad de la base de datos de STA incluye los siguientes tipos de archivo:
Logs de administración de daemon de servicios y servicio de copia de seguridad de STA
Archivos de configuración del daemon de servicios de STA y WebLogic
Su función es registrar las actividades del servidor del daemon de servicios de STA, STAServer, y la utilidad de configuración de servicios de copia de seguridad correspondiente, ServerAdm. Los logs de administración son conjuntos de hasta 10 archivos log, cada uno de hasta 1,0 MB. Los nombres de los archivos log tienen el formato *.log.N, donde N es el número del log (staservd.log.0, staservadm.log.0, staservd.log.1, etc.).
Se hace una rotación de los logs, de manera que el archivo log #1 se vuelve a utilizar cuando se complete el archivo staservd.log.9. El archivo log activo siempre es el #0 (staservd.log.0). Cuando se completa el log #0 se le cambia el nombre por log #1 y se inicia un nuevo log #0. De forma predeterminada, los logs de STAServer y ServerAdm se encuentran en el siguiente directorio:
/STA_logs/db/backups
La ubicación predeterminada de STA_logs es /var/log/tbi.
La ubicación y el formato interno de log (texto ASCII simple o marcas XML) están determinados por los archivos de propiedades de log staservd.log.props y staservadm.log.props, que se encuentran en:
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
Donde:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
El archivo de volcado de base de datos MySQL es una instantánea del esquema y el contenido de datos de la base de datos en un momento dado. El servicio de copia de seguridad de STA realiza estas acciones:
Inicia un volcado de alta velocidad (a veces llamado copia de seguridad en caliente) una vez cada 24 horas de los tipos de archivos que se indican en esta sección.
Transfiere el archivo de volcado más reciente al host de copia de seguridad designado.
Suprime del directorio de copia de seguridad local todos los archivos de volcado del día anterior.
Escribe una copia del archivo de volcado del día en curso en el directorio de copia de seguridad local.
De manera predeterminada, el servicio de copia de seguridad de STA coloca los archivos de volcado local y los archivos log binario (binlog) incrementales en el directorio /sta_db_backup/local con el formato AAAAMMDD_HHMMSS.nombre de archivo.sql.
El término volcados incrementales hace referencia a los logs binarios de MySQL (binlogs) que registran todas las transacciones que generan cambios en la base de datos. El servicio de copia de seguridad de STA trata a los logs binarios como copias de seguridad incrementales posteriores al volcado de la base de datos principal.
Los volcados incrementales de STA están compuestos por todos los logs binarios producidos desde el último volcado completo. La reproducción de los logs binarios permite restaurar el estado de la base de datos hasta la última transacción registrada en el archivo log. La restauración es la carga del archivo de volcado más reciente, y posteriormente la reproducción, en orden, de todos los logs binarios de MySQL que se hubieran generado después del volcado más reciente de la base de datos.
La copia de seguridad de los logs binarios consiste en hacer una lista de todos los logs binarios creados desde el volcado completo más reciente y después transmitir cada uno de esos logs (excepto el actual, que todavía está abierto) al servidor de copia de seguridad.
El formato de nomenclatura de los logs binarios de copia de seguridad es AAAAMMDD_HHMMSS.stadb–bin.log_sequence_number.
La ubicación de los logs binarios de MySQL se define en el archivo de configuración de MySQL /etc/my.cnf. Actualmente se encuentra en:
/STA_logs/db
Las copias locales de los archivos log binarios de copia de seguridad se encuentran en:
/sta_db_backup/local
Todos los logs binarios que se hayan transferido correctamente al servidor de copia de seguridad, con la excepción del más reciente, se depuran mediante el comando de MySQL PURGE BINARY LOGS BEFORE NOW(). Así, el log binario actual y el archivo de copia de seguridad completa del día actual permanecen en el servidor.
Atención:
Nunca suprima manualmente los archivos log binarios.Además de los archivos necesarios para recuperar la base de datos de aplicaciones de STA, el servicio de copia de seguridad de STA también hace copias de seguridad de los archivos de configuración de WebLogic de STA y sus propios archivos de configuración del daemon de servicios de STA. La copia de seguridad es recursiva e incluye todos los archivos y los directorios que se encuentran en los directorios de configuración respectivos.
Las copias de seguridad de los archivos de configuración se realizan una vez cada 24 horas, cuando se realiza el volcado completo de la base de datos de STA. El formato de los nombres de archivo de copia de seguridad es AAAAMMDD_HHMMSS.nombre de archivo.zip.gz.
Las ubicaciones de origen y destino de estas copias de seguridad se muestran en la Tabla 2-2:
Tabla 2-2 Ubicaciones de origen y destino de copia de seguridad
| Ubicación de origen | Copia local | Copia remota |
|---|---|---|
|
$STAHOME/common/conf/* |
$BACKUPS/AAAAMMDD_HHMMSS.conf.zip |
$RHOST:$RDIR/AAAAMMDD_HHMMSS.conf.zip.gz |
|
$WLHOME/config/fmconfig/* |
$BACKUPS/AAAAMMDD_HHMMSS.fmconfig.zip |
$RHOST:$RDIR/AAAAMMDD_HHMMSS.fmconfig.zip.gz |
Donde:
$STAHOME = /Oracle_storage_home/StorageTek_Tape_Analytics
$WLHOME = /Oracle_storage_home/Middleware/user_projects/domains/TBI
$BACKUPS =/dbdata/mysql/backups
$RHOST = dirección IP o nombre del servidor de copia de seguridad
$RDIR = directorio en el servidor de copia de seguridad
En las operaciones de supervisión de recursos, se utilizan dos clases de archivos:
Registran las actividades del daemon de servicios de STA y la utilidad de administración de supervisión de recursos, staresmonadm. Estos logs son conjuntos de hasta 10 archivos de log, cada uno de hasta 1,0 MB. Los nombres de los archivos log tienen el formato *.log.N, donde N es el número del log (staservd.log.0, staservadm.log.0, staservd.log.1, etc.).
Se hace una rotación de los logs, de manera que el archivo log #1 se vuelve a utilizar cuando se complete el archivo staservd.log.9. El archivo log activo siempre es el #0 (staservd.log.0). Cuando se completa el log #0 se le cambia el nombre por log #1 y se inicia un nuevo log #0. De manera predeterminada, los logs de servicios de STA, supervisión de recursos de STA y administración de supervisión de recursos de STA se encuentran en:
/STA_logs/db/backups
La ubicación y el formato interno de log (texto ASCII simple o marcas XML) están determinados por los archivos de propiedades de log staservd.log.props y staresmonadm.log.props, que se encuentran en:
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
Donde:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
Cada vez que el servicio de supervisión de recursos analiza el sistema, escribe los valores recopilados en un archivo de valores separados por comas (CSV) que, de manera predeterminada, se encuentra en:
/STA_logs/db/staresmon.csv
Este archivo de datos se puede cargar en programas como Excel y MySQL para realizar diversas funciones de análisis y trazado de gráficos con valores basados en el tiempo (por ejemplo, análisis de tendencias de agotamiento de recursos).
Nota:
El servicio de copia de seguridad de STA no depura ni revierte el archivo CSV del servicio de supervisión de recursos, ni realiza una copia de seguridad de este.Cada registro del archivo staresmon.csv representa un análisis del sistema. El formato del registro de 21 columnas se muestra en la Tabla 2-3.
Tabla 2-3 Formato de archivo CSV de supervisión de recursos
| Col. | Cabecera | Descripción | Formato |
|---|---|---|---|
|
1 |
TIMESTAMP |
Fecha y hora del análisis |
"AAAA–MM–DD HH:MM:SS" |
|
2 |
TS_MB_MAX |
Espacio de tabla máximo |
123 |
|
3 |
TS_MB_USED |
Espacio de base de datos usado total |
123 |
|
4 |
TS_MB_AVAIL |
Espacio de base de datos restante |
123 |
|
5 |
TS_PCT_USED |
Espacio de tablas de base de datos usado como porcentaje del máximo |
12,34% |
|
6 |
TS_PCT_HWM |
Límite superior de espacio de tablas de base de datos como porcentaje del máximo |
12,34% |
|
7 |
DBVOL_MB_MAX |
Espacio disponible máximo en el volumen que contiene la base de datos |
123 |
|
8 |
DBVOL_MB_USED |
Espacio de volumen de disco de base de datos total usado |
123 |
|
9 |
DBVOL_MB_AVAIL |
Espacio de disco de volumen de base de datos restante |
123 |
|
10 |
DBVOL_PCT_USED |
Espacio de disco de volumen de base de datos usado como porcentaje del máximo |
12,34% |
|
11 |
DBVOL_PCT_HWM |
Límite superior de volumen de base de datos como porcentaje del máximo |
12,34% |
|
12 |
LOGVOL_MB_MAX |
Espacio disponible máximo en el volumen que contiene los logs |
123 |
|
13 |
LOGVOL_MB_USED |
Espacio de volumen de disco de log total usado |
123 |
|
14 |
LOGVOL_MB_AVAIL |
Espacio de disco de volumen de log restante |
123 |
|
15 |
LOGVOL_PCT_USED |
Espacio de disco de volumen de log usado como porcentaje del máximo |
12,34% |
|
16 |
LOGVOL_PCT_HWM |
Límite superior de volumen de log como porcentaje del máximo |
12,34% |
|
17 |
MEM_MB_MAX |
RAM física instalada máxima |
123 |
|
18 |
MEM_MB_USED |
Memoria física total usada |
123 |
|
19 |
MEM_MB_AVAIL |
Espacio de memoria física restante |
123 |
|
20 |
MEM_PCT_USED |
Espacio de memoria física usado como porcentaje del máximo |
12,34% |
|
21 |
MEM_PCT_HWM |
Límite superior de memoria física como porcentaje del máximo |
12,34% |
La generación de archivos de log para el daemon de servicios de STA, el servicio de copia de seguridad, la utilidad de administración del servicio de copia de seguridad y la utilidad de supervisión de recursos de STA se controla mediante los siguientes archivos de configuración de log:
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
Donde $STA_HOME es la ubicación inicial de STA especificada durante la instalación de STA; consulte la información detallada en Guía de instalación y configuración de STA.
El contenido y el formato del archivo log se controlan mediante las propiedades del gestor de logs de Java en estos archivos. En la Tabla 2-4 se resumen las propiedades. Para obtener información detallada adicional, consulte la documentación de Java SE de Oracle en el siguiente sitio:
http://docs.oracle.com/en/java/
Tabla 2-4 Propiedades de log de Java
| Propiedad | Descripción | Configuración de STA |
|---|---|---|
|
java.util.logging.FileHandler.append |
Especifica si el manejador de archivos se debe agregar a los archivos existentes. El valor predeterminado es false. |
true |
|
java.util.logging.FileHandler.count |
Especifica la cantidad de archivos de salida del ciclo. El valor predeterminado es 1. |
10 |
|
java.util.logging.FileHandler.formatter |
Especifica el nombre de clase del formateador. El valor predeterminado es java.util.logging.XMLFormatter. |
Java.util.logging.SimpleFormatter para lectura por seres humanos. java.util.logging.XMLFormatter se comenta y está disponible. |
|
java.util.logging.FileHandler.level |
Especifica el nivel predeterminado del manejador. El valor predeterminado es Level. ALL. |
CONFIG |
|
java.util.logging.FileHandler.limit |
Especifica la cantidad máxima aproximada de bytes para escribir en un archivo. Cero indica que no hay límite. El valor predeterminado es no limit. |
500000 (0,5 MB) |
|
java.util.logging.FileHandler.pattern |
Especifica el patrón de nombre del archivo de salida. El valor predeterminado es "%h/java%u.log". |
/STA_logs/db/backups/staservd.log.%g /STA_logs/db/backups/staservadm.log.%g Donde STA_logs es la ubicación de los archivos log establecida durante la instalación de Linux; consulte la información detallada en la Guía de instalación y configuración de STA. |
Los niveles de log están controlados por las propiedades de log de STA en estos archivos. En la Tabla 2-5 se resumen las propiedades.
Tabla 2-5 Propiedades de log de servicios de STA
| Propiedad | Descripción | Configuración de STA |
|---|---|---|
|
oracle.tbi.server.level |
Especifica el nivel de log del servidor. |
CONFIG |
|
oracle.tbi.serveradm.level |
Especifica el nivel de log de las funciones de administración del servidor. |
CONFIG |
|
oracle.tbi.resmonadm.level |
Especifica el nivel de log de las funciones de administración de supervisión de recursos. |
CONFIG |
El procedimiento de restauración de bases de datos de STA consiste en cargar el volcado completo más reciente de la base de datos y después reproducir todos los logs binarios inmediatamente posteriores al volcado.
En el directorio del servidor de copia de seguridad hay juegos de archivos de copia de seguridad bien diferenciados. Por ejemplo:
# cd /data/stabackups
# ls –1
20130721_133755.conf.zip.gz 20130721_133755.fmwconfig.zip.gz 20130721_133755.stadb-bin.000024.gz 20130721_133755.stafullbackup.sql.gz 20130722_133755.conf.zip.gz 20130722_133755.fmwconfig.zip.gz 20130722_133755.stadb-bin.000024.gz 20130722_133755.stafullbackup.sql.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000021.gz 20130723_133755.stadb-bin.000022.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.stadb-bin.000024.gz 20130723_133755.stafullbackup.sql.gz
El formato de registro de hora del nombre de archivo es AAAAMMDD_HHMMSS. Todos los logs binarios que tengan la misma etiqueta de fecha se reproducen en la base de datos después de cargar el volcado completo.
En esta sección, se analizan las siguientes tareas de administración:
Use este procedimiento para copiar archivos de copia de seguridad al servidor de STA.
Copie el juego completo de archivos del día nuevamente en el servidor de STA.
Oracle recomienda copiar todo en el directorio /tmp. Por ejemplo, suponiendo que STA esté instalado en el servidor sta.server.com y usted esté actualmente conectado al servidor de copia de seguridad.
# scp 20130723*.* sta.server.com:/tmp/.
Password:
Inicie sesión en el servidor de STA como root.
Descomprima los archivos *.gz. Por ejemplo:
# cd /tmp
# gunzip 20130723*.*.gz
Use este procedimiento para restaurar los archivos del directorio de configuración.
Detenga todos los procesos de STA. A continuación, reinicie solo el servidor de MySQL.
# STA stop all
# STA start mysql
Descomprima los directorios de configuración de STAServer y el daemon de servicios de STA.
Los archivos zip se crearon con las rutas de directorio completas para que sea posible restaurar o sobrescribir archivos existentes. El comando unzip le permite restablecer la raíz de la ruta de restauración con la opción –d. Hay opciones adicionales que permiten lograr un mayor control, por ejemplo, el reemplazo selectivo.
Para una restauración desde cero, debe reemplazar por completo el directorio de configuración existente. Sin embargo, haga antes una copia de seguridad del directorio original. Por ejemplo:
# cd $WLSHOME
# zip –vr fmwconfig.orig.zip fmwconfig
# rm –rf fmwconfig
# cd /tmp
# unzip –X –d/ 20130723_133755.fmwconfig.zip
# cd $STAHOME/common
# zip –vr conf.orig.zip conf
# rm –rf conf
# cd /tmp
# unzip –X –d/ 20130723_133755.conf.zip
Donde:
$WLSHOME =/Oracle_storage_home/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
Ejecute los siguientes comandos como usuario root de MySQL.
Para volver a cargar la base de datos:
Elimine la base de datos residual de stadb, si hay una. Por ejemplo:
# mysql –uroot –p –e 'drop database stadb;'
Password:
Cargue el volcado completo más reciente. Al hacerlo, se crea el esquema y se instalan todos los datos. Por ejemplo:
# mysql –uroot –p –e 'source 20130723_133755.stafullbackup.sql;'
Password:
Para reproducir los logs binarios:
Ejecute cada uno de los volcados incrementales (logs binarios), de más reciente a más antiguo.
Si tiene más de un log binario para ejecutar en el servidor de MySQL, el método más seguro es procesar todos los archivos mediante una única conexión con el servidor y un único proceso MySQL para ejecutar el contenido de todos los logs binarios.
Por ejemplo:
# mysqlbinlog 20130723_133755.sta-binlog.000021 \
> 20130723_133755.sta-binlog.000022 \
> 20130723_133755.sta-binlog.000023 \
> 20130723_133755.sta-binlog.000024 |mysql –u root –p
Otro enfoque es concatenar todos los logs en un único archivo y después procesar ese archivo:
# mysqlbinlog 20130723_133755.sta-binlog.000021 > /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000022 >> /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000023 >> /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000024 >> /tmp/recoversta.sql
# mysql –u root –p –e 'source /tmp/recoversta.sql'
Nota:
Si no proporciona una contraseña en la línea de comandos, MySQL se la solicita antes de continuar.El procesamiento de los logs binarios, como el que se muestra en el siguiente ejemplo, puede crear varias conexiones con el servidor. La existencia de más de una conexión ocasiona problemas si el primer archivo log contiene la instrucción CREATE TEMPORARY TABLE y el segundo log contiene una instrucción que usa esa tabla temporaria. Cuando finaliza el primer proceso de MySQL, el servidor elimina la tabla temporaria. Cuando el segundo proceso de MySQL intenta usar esa tabla, el servidor informa "unknown table" (tabla desconocida).
# mysqlbinlog binlog.000001 |mysql –u root –p #<=== DANGER!!
# mysqlbinlog binlog.000002 |mysql –u root –p #<=== DANGER!!
Como usuario root del sistema Linux, introduzca el siguiente comando:
# STA start all
Otro método de restauración es el de las restauraciones puntuales, en el que se pueden reproducir los logs binarios desde un momento específico hasta un momento específico.
Por ejemplo, después de examinar el contenido de un log binario, descubre que una operación errónea hizo que se eliminaran varias tablas inmediatamente después de la entrada de log #6817916. Después de restaurar la base de datos a partir del volcado completo que se realizó el día anterior, y antes de reiniciar todos los servicios de STA, puede usar los comandos que se muestran en este procedimiento para reproducir el log binario más reciente desde el número de entrada de log inicial "176" hasta el número de entrada "6817916".
Use este procedimiento para restaurar la base de datos de STA a partir de un rango de números de log.
Asegúrese de que todos los procesos de STA estén cerrados y que se esté ejecutando solo el servidor de MySQL:
# STA stop all
# STA start mysql
Como usuario root de MySQL, extraiga las operaciones válidas. Por ejemplo:
# mysqlbinlog ––start–position=176 ––stop–position=6817916
/var/log/tbi/db/stadb–bin.000007 > ./recover.sql
Aplíquelas a la base de datos. Por ejemplo:
# mysql –uroot –p –e 'source ./recover.sql'
Password:
Como usuario root del sistema Linux, reinicie la aplicación de STA y el daemon de servicios de STA:
# STA start all
Para obtener más información acerca de las operaciones de recuperación puntual o incremental, consulte la documentación de MySQL en el siguiente sitio: