| StorageTek Tape Analytics Guía de administración Versión 2.0 E53285-01 |
|
 Anterior |
 Siguiente |
| StorageTek Tape Analytics Guía de administración Versión 2.0 E53285-01 |
|
Anterior |
Siguiente |
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 el capítulo ”Configuración de servicios de STA” en la Guía de instalación y configuración de STA.
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 copias de seguridad de STA y el servicio de supervisión de recursos de STA. Tanto el servicio de copias de seguridad de STA como el servicio de supervisión de recursos de STA se ejecutan como procesos de ejecución independientes en el daemon de servicios de STA.
El daemon de servicios de STA se inicia cuando el servidor de STA arranca (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 Capítulo 2, "Administración del servidor."
|
Nota: Después de la instalación de STA, se inicia el daemon de servicios de STA junto con los servicios de copia de seguridad y supervisión de recursos de STA, pero no se los activa hasta que se los configure. Para configurar estos servicios, consulte el capítulo "Configuración de servicios de STA" en 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, asegúrese de que el daemon de servicios de STA se esté ejecutando. Consulte "Daemon de servicios de STA".
"Visualización de la configuración de preferencias del servicio de copia de seguridad"
"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/StorageTek_Tape_Analytics/common/bin. Para configurar el servicio de copia de seguridad de STA, consulte el capítulo ”Configuración de servicios de STA” en 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 /dbbackup/local del servidor de STA.
Introduzca el siguiente comando para ver el estado de la configuración actual de las preferencias:
# ./staservadm -Q
Si el campo "Configured" (Configurado) dice ”no,” significa que el servicio de copia de seguridad se está ejecutando en el modo ”inactivo” y no se está realizando ninguna copia de seguridad. Deberá proporcionar los parámetros de configuración adecuados, según se indica en la Guía de instalación y configuración de STA.
Ejemplo de salida de un servicio de copia de seguridad de STA configurado:
# ./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 [*********]
Introduzca el siguiente comando para borrar la configuración actual de las preferencias:
# ./staservadm -C
El servicio de copia de seguridad ya no está configurado y regresará al estado ”inactivo”. Ahora puede proporcionar una nueva configuración según se indica en la Guía de instalación y configuración de StorageTek Tape Analytics. Por ejemplo:
# ./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 []
Para verificar que los archivos se hayan enviado correctamente:
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.
El archivo staservd.log.0 registra las actividades de la utilidad de configuración de los servicios de copia de seguridad.
Cambie el directorio de trabajo al directorio de log de copia de seguridad de STA.
# cd /var/log/tbi/db/backups
Busque en el archivo staservd.log.0 la cadena ”INFO: done. Database dump completed.”
# 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. En este ejemplo, el directorio /backups/tbivb01 fue configurado 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 /dbbackup/local:
# ls -l /dbbackup/local
20130721_133755.conf.zip
20130721_133755.fmwconfig.zip
20130721_133755.stafullbackup.zip
Los archivos enumerados tendrán el formato AAAAMMDD_HHMMSS.nombre del archivo.zip.
El servicio de supervisión de recursos de STA, como su nombre lo indica, 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 supervisor de recursos de STA"
El servicio de supervisión de recursos de STA se configura mediante la utilidad de administración asociada, staresmonadm, que se encuentra en /Oracle/StorageTek_Tape_Analytics/common/bin. Para configurar el servicio de supervisión de recursos de STA, consulte el capítulo ”Configuración de servicios de STA” en 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. Ahora deberá configurar el servidor según se indica en la Guía de instalación y configuración de StorageTek Tape Analytics.
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 servicios ya no está configurado y regresará al estado ”inactivo”. Ahora puede proporcionar una nueva configuración según se indica en la Guía de instalación y configuración de StorageTek Tape Analytics. 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]
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 el capítulo ”Configuración de servicios de STA” en 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 por 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 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 (-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 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:
/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 secuencia de comandos staservd init y los enlaces simbólicos asociados son creados por el instalador de STA.
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á contenida en el archivo oracle.tbi.serveradm.jar. Para obtener más información, consulte "Servicio de copia de seguridad de STA".
La utilidad de administración del supervisor de recursos de STA, staresmonadm, es una secuencia de comandos Perl que llama a una aplicación cliente Java llamada StaResMonAdm que está contenida 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 "Servicio de supervisión de recursos de STA".
Tabla 3-1 enumera los programas ejecutables y sus ubicaciones.
Tabla 3-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 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/StorageTek_Tape_Analytics
En la operación de copia de seguridad, se utilizan las siguientes clases de archivos:
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
Registran las actividades del servidor del daemon de servicios de STA, STAServer, y su utilidad de configuración de servicios de copia de seguridad, 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 circular de los logs, de manera que el archivo log #1 se vuelve a utilizar cuando se completa 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:
/var/log/tbi/db/backups
La ubicación y el tipo de formato de log interno (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/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 /dbbackup/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 AAAMMDD_HHMMSS.stadb-bin.número_secuencia_log.
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:
/var/log/tbi/db/
Las copias locales de los archivos de log binario de copia de seguridad se encuentran en:
/dbbackup/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.
|
Precaución: Nunca suprima manualmente los archivos de log binario. |
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 los archivos de copia de seguridad es AAAAMMDD_HHMMSS.nombre del archivo.zip.gz.
Las ubicaciones de origen y destino de estas copias de seguridad se muestran en Tabla 3-2:
Tabla 3-2 Ubicaciones de origen y destino de copia de seguridad
| Ubicación de origen | Copia local | Copia remota |
|---|---|---|
|
$STAHOME/common/conf/* |
$BACKUPS/AAAMMDD_HHMMSS.conf.zip |
$RHOST:$RDIR/AAAMMDD_HHMMSS.conf.zip.gz |
|
$WLHOME/config/fmconfig/* |
$BACKUPS/AAAAMMDD_HHMMSS.fmconfig.zip |
$RHOST:$RDIR/AAAAMMDD_HHMMSS.fmconfig.zip.gz |
Donde:
$STAHOME =/Oracle/StorageTek_Tape_Analytics
$WLHOME =/Oracle/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, staresmonadm.log.0, staservd.log.1, etc.).
Se hace una rotación circular de los logs, de manera que el archivo log #1 se vuelve a utilizar cuando se completa 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:
/var/log/tbi/db/backups
La ubicación y el formato 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/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:
/var/log/tbi/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 no depura, revierte ni incluye el archivo CSV del servicio de supervisión de recursos en las copias de seguridad. |
Cada registro del archivo staresmon.csv representa un análisis del sistema. El formato del registro de 21 columnas se muestra en Tabla 3-3.
Tabla 3-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 archivos de configuración de log que se encuentran en:
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
Donde:
$STAHOME =/Oracle/StorageTek_Tape_Analytics
El contenido y el formato del archivo log se inicializan y controlan mediante las propiedades de configuración del gestor de logs de Java. Estas propiedades se leen de los archivos de propiedades de log indicadas anteriormente. La siguiente información se puede encontrar en:
http://download.oracle.com/javase/1.4.2/docs/api/java/util/logging/FileHandler.html.
Tabla 3-4 Contenido de archivo log
| Propiedad | Descripción | Configuración de StorageTek Tape Analytics |
|---|---|---|
|
java.util.logging.FileHandler.append |
Especifica si se debe anexar FileHandler a los archivos existentes (la configuración predeterminada es "false"). |
true |
|
java.util.logging.FileHandler.count |
Especifica la cantidad de archivos de salida del ciclo (la configuración predeterminada es 1). |
10 |
|
java.util.logging.FileHandler.formatter |
Especifica el nombre de clase de formateador que se utiliza (la configuración predeterminada es java.util.logging.XMLFormatter) |
Java.util.logging.SimpleFormatter para lectura por seres humanos. java.util.loggin.XMLFormatter se convierte en comentario y está disponible |
|
java.util.logging.FileHandler.level |
Especifica el nivel por defecto del manejador (la configuración predeterminada es Level. ALL). |
CONFIG |
|
java.util.logging.FileHandler.limit |
Especifica una cantidad máxima aproximada (en bytes) para escribir en un archivo. Si este valor es cero, no hay límite. (La configuración predeterminada es sin límite). |
1000000 (1MB) |
|
java.util.logging.FileHandler.pattern |
Especifica un patrón para generar el nombre del archivo de salida. Para obtener más información, consulte la información que se muestra abajo. (La configuración predeterminada es "%h/java%u.log"). |
/var/log/tbi/db/backups/staservd.log.%g /var/log/tbi/db/backups/staservadm.log.%g |
Tabla 3-5 Propiedades del daemon de servicios de STA
| Propiedad | Descripción | Configuración de StorageTek Tape Analytics |
|---|---|---|
|
oracle.tbi.server.level oracle.tbi.serveradm.level oracle.tbi.resmonadm.level |
Especifica el nivel de log del servidor, las funciones de administración del servidor o las funciones de administración del supervisor de recursos. |
CONFIG CONFIG |
El procedimiento de restauración de STA consiste en cargar el volcado completo más reciente 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 la marca de tiempo 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:
Para copiar archivos de copia de seguridad en el servidor:
Copie el juego completo de archivos del día en el servidor de STA.
Oracle recomienda copiar todo lo que haya 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 como usuario root en el servidor de STA y descomprima los archivos *.gz. Por ejemplo:
# cd /tmp # gunzip 20130723*.*.gz
Para restaurar los archivos del directorio de configuración:
Detenga todos los procesos del STA. A continuación, reinicie sólo 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 y/o sobrescribir archivos existentes. El comando zip 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/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle/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 y 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".
Para restaurar 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 sólo 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 el manual de MySQL:
http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html
|
 Copyright © 2012, 2014, Oracle y/o sus filiales. Todos los derechos reservados. Avisos Legales |
|