hacer - ¿Cuáles son los escenarios para usar el reflejo, el envío de registros, la replicación y la agrupación en SQL Server?
que es mirroring en sql server (3)
Por lo que sé SQL Server proporciona 4 técnicas para una mejor disponibilidad.
Creo que estos son los escenarios de uso primarios, en resumen:
1) La replicación sería adecuada principalmente para escenarios de sincronización de datos en línea-fuera de línea (computadora portátil, dispositivos móviles, servidores remotos).
2) El envío de registros podría usarse para tener un servidor de conmutación por error con conmutación manual, mientras que
3) Database Mirroring es una técnica automática de failover
4) Failover Clustering es un tipo avanzado de creación de reflejo de la base de datos.
Estoy en lo correcto?
Gracias.
El clúster de conmutación por error es una tecnología de disponibilidad que proporciona redundancia a nivel de hardware y se basa en la tecnología de Clustering de Windows, es decir, no es específico de SQL Server.
Por ejemplo, el procesador explota en el Servidor A. Afortunadamente, el Servidor A es parte de un Clúster de Servidor SQL y, por lo tanto, el Servidor B se hace cargo del trabajo de proporcionar el Servicio de Servidor SQL, en cuestión de segundos. Todo esto ocurre de manera automática y es transparente para los usuarios de la base de datos y / o para la aplicación a la que da servicio el clúster.
La diferencia principal entre la creación de reflejo de la base de datos y la agrupación en clústeres es que la agrupación en clústeres de SQL proporciona redundancia en el nivel de instancia, mientras que la creación de reflejo de la base de datos proporciona redundancia en el nivel de la base de datos.
El siguiente enlace proporciona una comparación entre estas dos tecnologías que puede encontrar de uso.
http://msdn.microsoft.com/en-us/library/ms191309(SQL.90).aspx
El envío de registros se considera más una tecnología de redundancia.
Por ejemplo, se puede utilizar para proporcionar una copia completa de su entorno principal, generalmente se utiliza como un modo de espera en caliente que se puede poner en línea manualmente. Esto se puede utilizar para proporcionar redundancia adicional a su estrategia de respaldo. El envío de registros también se puede utilizar para descargar los informes de un servidor primario mediante la creación de una copia de solo lectura de la base de datos de producción en una ubicación / servidor alternativo.
La replicación es una tecnología bastante diversa y se puede usar para atender una serie de escenarios diferentes, cuya elección determinará el tipo específico de replicación que se implementa.
Por ejemplo, la duplicación de mezcla puede usarse para soportar el procesamiento distribuido al distribuir la carga de trabajo de una aplicación a través de varios servidores, es decir, arquitecturas de procesamiento distribuido.
La replicación de mezcla a menudo requiere una aplicación que sea relativamente consciente de su entorno. Las técnicas como la resolución de conflictos también deben tenerse en cuenta para garantizar la coherencia de los datos en todo el entorno integrado.
La replicación transaccional se puede usar de manera similar al envío de registros, sin embargo, puede limitar los objetos específicos que se replican al suscriptor. Esto puede ser útil si solo se requiere un subconjunto de tablas para los informes.
Espero que esto te aclare un poco las cosas. Puede encontrar una gran cantidad de documentación sobre cada una de estas tecnologías en los libros de SQL Server en línea, o buscando cada tecnología en Google. Dicho esto, si tiene alguna consulta específica, me gustaría ayudarlo, así que siéntase libre de escribirme.
Saludos, John
El envío y la replicación de registros AFAIK probablemente serían más adecuados al revés.
El envío de registros es sincronización programada, por lo tanto, la replicación sería más adecuada para el cambio manual porque el servidor de respaldo estaría actualizado a menos que tuvieras algún problema de comunicación (sin embargo, el envío de registros tendría el mismo problema).
offline-data no es tan sensible a las demoras como servidor de respaldo, pero personalmente no veo realmente la necesidad de un log-shipping, no puedo ver cuándo podría ser una alternativa más adecuada para la replicación ( pero podría ser que la replicación no se implementó antes de sql2005)
Tal vez estoy confundiendo la replicación con la creación de reflejos, y como una nota, la creación de reflejos no le da failover automático, solo HA-cluster le da esa funcionalidad, lo que significa:
utilizando por lo menos SQL Server 2005 estándar, Windows Enterprise y un almacenamiento de datos compartido (como una SAN).
En SQL 2008 Enterprise también hay algo llamado Change Data Capture (CDC) que estamos utilizando con éxito donde trabajo.
Tenemos una base de datos demasiado normalizada que hace que sea muy difícil obtener información. Necesitábamos cambiar la estructura de datos al mismo tiempo que replicamos estos datos a otro servidor para informes y demás.
Funciona extremadamente bien para nosotros.