Sistemas afectados
Bases de Datos en direcci贸n IP de Intranet 192.168.0.59
Bases de Datos en direcci贸n IP de Intranet 192.168.0.193
Estado de situaci贸n
Al presente el acceso a las bases de datos correspondientes a las
direcciones de IP de Intranet mencionadas se encuentra reestablecido al
m谩ximo posible.
Sobre 3577 bases de datos afectadas, 2922 (82%) se encuentran nuevamente
disponibles con la informaci贸n retrotra铆da a los meses de Enero y Febrero principalmente, Marzo a Junio en un porcentaje menor.
Las 655 (18%) bases de datos restantes no se encuentran en un estado que
pueda ser recuperado a producci贸n.
Reporte
El d铆a Lunes 13/06 por la ma帽ana nuestro equipo not贸 una degradaci贸n de
performance severa en cuanto a la velocidad de respuesta del servicio.
Esta situaci贸n generaba demora en la carga de sitios de clientes por
arriba de niveles aceptables por lo que nuestro equipo t茅cnico decidi贸
realizar una suspensi贸n de urgencia del servicio para realizar un
upgrade de hardware, considerando preferible un corte momentaneo a aguardar a un horario nocturno, ya que el servicio estar铆a severamente
degradado durante el d铆a caso contrario.
Durante el proceso de actualizaci贸n de hardware, una rutina
perfectamente normal en estas situaciones fall贸. Esto ocasion贸 la
perdida total de acceso a todos los datos contenidos. Al tratarse de una
falla en software, y no en hardware, no hubo inconvenientes con el
almacenamiento redundante (RAID), sino en la capa superior. Dicha capa,
a la vez, gestiona el sistema de SnapShots MySQL.
A partir de dicho momento, cercano a las 14.30pm del 13/06 el acceso se
interrumpi贸 por completo, no siendo restaurado de forma parcial hasta
las 18hs. Desde las 18hs del 13/06 hasta las 18hs del 15/06 la
informaci贸n disponible en un respaldo offsite independiente de los
Snapshots (f铆sicamente separado) de las bases afectadas se fue
restaurando paulatinamente. Este proceso es lento, y la informaci贸n
offsite es m谩s antigua que la de nuestros Snapshots internos.
Detalle T茅cnico
El servicio de MySQL SnapShots, integrado a las cuentas Grid 2.0 y
MultiCuenta fue lanzado en 2009 con el objetivo de brindar un acceso
r谩pido y c贸modo a informaci贸n de d铆as pasados (10) de los datos MySQL de
nuestros clientes.
El desaf铆o de respaldar MySQL es la realizaci贸n On-Line de los mismos:
Poder tomarlos sin necesidad de interrumpir el servicio.
Nuestra plataforma MySQL est谩 basada en Linux (kernel 2.6) + MySQL (5.1
o superior), EXT3 como sistema de archivos y LVM (Logical Volume
Manager) para la gesti贸n de discos, utilizando RAID1.
LVM nos permite tomar Snapshots (similar a fotograf铆as en momentos
determinados de los datos), sin interrumpir acceso a los datos en vivo,
y sin necesidad de duplicar (en nuestro caso por 10), la informaci贸n que
queremos brindar en un snapshot.

Lo anterior nos permite una soluci贸n versatil en productos con un costo
total inferior a u$s1 mensual (sitios de multicuenta).
Debido a que tanto Snapshots como datos participan de los mismos discos
f铆sicos, los mismos se hayan protegidos contra fallas de hardware usando
sistemas RAID1.
LVM es un software ampliamente utilizado y probado, y hasta ahora,
perfectamente confiable. El bug en LVM que gener贸 la corrupci贸n de
bloques y metadatos de uno de nuestros servidores, sumado a nuestro
error de trabajar con un equipo en producci贸n gener贸 como consecuencia
el resultado que ahora existe. En condiciones normales, se separa
siempre parte del raid previo a cualquier tarea para tener una copia
independiente de todo el sistema.
Medidas a tomar
Desde hace 6 meses nos encontramos actualizando nuestro sistema de
Snapshots y MySQL, con servicio basado en Solaris+ZFS en lugar de
Linux+EXT3+LVM. Esta nueva versi贸n nos permite tomar Snapshots con la
misma funcionalidad que lo anterior, excepto que dichos Snapshots se
encuentran en su -totalidad- en servidores offsite, es decir que aun en
un evento como el de este 13/06 no afectar铆a la disponibilidad de los
datos m谩s all谩 de los 煤ltimos minutos (Snapshots via ZFS los tomamos
cada 60 minutos, contra 24 horas de LVM)
Actualmente menos de un 30% de nuestra red utiliza esta nueva
tecnolog铆a. Vamos a acelerar la migraci贸n de sistema para poder aumentar
las garant铆as ofrecidas a todos nuestros clientes cuanto antes.
Adicionalmente, vamos a aumentar nuestros respaldos offsite manuales
para los sistemas Linux+EXT3+LVM a una vez por semana, hasta tanto la
migraci贸n a Solaris+ZFS est茅 finalizada.
Sobre ambos temas, mantendremos informaci贸n de avance actualizada.
Estamos al tanto de los inconvenientes que esto genera en nuestros
clientes, y queremos colaborar y asistir en todo lo que nos sea posible
para la normalizaci贸n de sus sitios.
Nuestro departamento de Atenci贸n al Cliente est谩 tomando contacto
telef贸nico con cada una de las cuentas afectadas para tratar uno por uno
cada caso particular en cuanto a las definiciones t茅cnicas y comerciales
necesarias.
Preguntas Frecuentes:
Veo mi base de datos en el Panel de Control, pero no puedo acceder.
Durante la restauraci贸n la informaci贸n de contrase帽as de acceso MySQL
fue blanqueada. Para poder volver acceder a tu base debes volver a crear
el usuario. Puede ser el mismo de antes o uno nuevo.
No veo mi base de datos en el Panel de Control. 驴Esto quiere decir que
no estar谩 disponible ?
Todav铆a estamos importando algunas bases de datos de nuestro backup
offsite. La misma va a finalizar a las 8am de ma帽ana 17/06. Si pasada este momento no se encuentra en tu panel implica que no estar谩 disponible.
Algunas tablas me figuran corruptas
Pod茅s correr un REPAIR TABLe (tabla) para que MySQL realice una
verificaci贸n. En caso que eso no funcione, contactanos.
驴Mis bases de datos ahora tienen nuevamente Snapshots?
Estamos tomando respaldos externos manuales diarios, durante el fin de
semana se normalizar谩 la toma de snapshots.