none
Replica solo lectura RRS feed

  • 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

    domingo, 8 de abril de 2012 14:43

Respuestas

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

    domingo, 8 de abril de 2012 15:14
    Moderador
  • 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



    domingo, 8 de abril de 2012 19:29
  • 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
    domingo, 15 de abril de 2012 21:03
  • 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
    lunes, 16 de abril de 2012 9:36
    Moderador
  • 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
    lunes, 16 de abril de 2012 20:27
    Moderador