Principales respuestas
Replica solo lectura

Pregunta
-
hola.
mi escenario es un cluster de tipo failover de 2 nosos sobre windows 2008 r2 y SQL 2008 R2, Con una unica instancia-A de SQL donde tengo las bases de datos de producción.
Ahora bien, me exigen tenter en otra instancia-B que no afecte a la instancia-A de producción (en rendimiento) una replica de una de las bases de datos de la instancia-A, esta replica de la base de datos solo ha de estar disponible para consulta (lectura).
hacer un snapshot diario pisando el antiguo, en la instancia-A, ya que solo quieren lectura, lo descartaron por motivos internos de la empresa, que ya se hacen otros y no quieren que se acceda a esta instancia para esto...
Pense en instalar una nueva instancia (instancia-B), en el otro nodo del mismo cluster... pera luego montar un mirroring que me ofrezca la bd en modo lectura... pero no tiene mucho sentido, pues el mirroring iria en un cluster failover y no es la logica del mismo... O montar unos JOBs que hagan backup restore diariamente de la instancia-A hacia la instancia-B, pues con tener los datos disponibles del dia anterior les vale...
Que se os ocurre, o que me aconsejan... si me ofrecen algun enlace de como hacer lo que me aconsejan se lo agradeccería doblemente.
Gracias
Respuestas
-
Puedes montarte algo parecido a lo que hace loghsipping sin pisar la secuencia de backups de SQL Server a través de la clasula COPY_ONLY del comando backup. Este comando se usa precisamente para eso, para no afectar la secuencia de backup.
El único problema es que los jobs, y los comandos, tanto de copiar archivos etc te los tienes que hacer a mano.. pero vamos.. muy complicado no es.
Comparte lo que sepas, aprende lo que no sepas (FGG)
portalSQL
El rincón del DBA- Marcado como respuesta SergioAlto lunes, 16 de abril de 2012 20:38
-
Hola.
Como dice Miguel, no es difícil. Hace unos cuantos años publiqué un artículo al respecto. Te ayudará a montarlo. No es log shipping, pero se asemeja mucho.
http://msdn.microsoft.com/es-es/library/bb972243.aspx
Pero por otra parte, nada te impide restaurar esos mismos backups que ya haces. De paso los verificas, algo que tienes que hacer de cualquier modo.
Alberto López Grande
SQL Server MVP
Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande- Marcado como respuesta SergioAlto lunes, 16 de abril de 2012 20:39
Todas las respuestas
-
Hola.
Tu escenario entra bastante bien en log shipping (no para alta disponibilidad sino para ese acceso de lectura). Es un conjunto de backups y restores del log de transacciones que puede configurarse para que esté accesible para lectura. Requiere que tengas una segunda instancia instalada, además de modelo de recuperación completo, pero dejándola en el otro nodo en el que no esté la instancia A el impacto será pequeño.
Encontrarás más información aquí:
http://msdn.microsoft.com/es-es/library/ms187103(v=sql.105).aspx
Si no te vale, nos dices, hay otras alternativas.
Alberto López Grande
SQL Server MVP
Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande- Propuesto como respuesta alfred_magno lunes, 9 de abril de 2012 15:20
- Marcado como respuesta Alberto López Grande (qwalgrande)Moderator domingo, 15 de abril de 2012 9:52
- Desmarcado como respuesta SergioAlto domingo, 15 de abril de 2012 21:04
-
Hola,
Actualmente tienes un modelo de alta disponibilidad basado en
cluster, para la necesidad que nos cuentas es necesario utilizar una estrategia
de replicación de datos que nos permita lectura en el nodo destino, para esto
las tecnologías de cluster y mirroring quedan descartadas, por lo cual quedan
dos disponibles Log Shipping como no lo cuenta alberto o la tecnologia de replicación
esta ultima en varios sabores (Transaccional, P2P, Merge).Cual escoger?, eso depende que demora de la información y que información
requieras en el nodo destino, me explico, si quieres solo unas tablas o una información
especifica o si quieres tener la información replicada transacción a transacción
la opción es replicación, de lo contrario si es la totalidad de la base de
datos y puedas tener un "posible" retardo de la información en el
nodo destino la opción es Log Shipping.Quedamos atentos si resolvimos tu inquietud o requieres ampliación.<o:p></o:p>
Javier M Castrillon
@jmcastrillon
- Editado Javier Mauricio Castrillon domingo, 8 de abril de 2012 19:32
-
Aunque la respuesta de Qwalgrande es valida... yo no la puedo usar... os cuento: Mi respaldo de backup de la bases de datos, se hace con TSM (IBM) usando el api del TDP que permite la comunicación de TSM con SQL... Si uso la tecnica de "log shipping" los backup que hace log shipping, me interrumpirian la secuencia de backups full diferenciales y log del TSM... por lo que en mi caso se descarta...
Finalmente, creo que optaremos por backup-Restore programado por TSM... aun continuamos dando vueltas y buscando alguna otra alternativa.
Javier, queremos descartar la replica transaccional de publicadores y subscriptores...
Podeis darme algo mas de informacioón sobre las replicas tipo P2P o Merge. (Merge conozco algo, pero P2P no me suena...)
Gracias
- Editado SergioAlto domingo, 15 de abril de 2012 21:05
-
Puedes montarte algo parecido a lo que hace loghsipping sin pisar la secuencia de backups de SQL Server a través de la clasula COPY_ONLY del comando backup. Este comando se usa precisamente para eso, para no afectar la secuencia de backup.
El único problema es que los jobs, y los comandos, tanto de copiar archivos etc te los tienes que hacer a mano.. pero vamos.. muy complicado no es.
Comparte lo que sepas, aprende lo que no sepas (FGG)
portalSQL
El rincón del DBA- Marcado como respuesta SergioAlto lunes, 16 de abril de 2012 20:38
-
Hola.
Como dice Miguel, no es difícil. Hace unos cuantos años publiqué un artículo al respecto. Te ayudará a montarlo. No es log shipping, pero se asemeja mucho.
http://msdn.microsoft.com/es-es/library/bb972243.aspx
Pero por otra parte, nada te impide restaurar esos mismos backups que ya haces. De paso los verificas, algo que tienes que hacer de cualquier modo.
Alberto López Grande
SQL Server MVP
Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande- Marcado como respuesta SergioAlto lunes, 16 de abril de 2012 20:39