Chose évidente, les technologies SharePoint sont intimement liées à SQL Server. Cependant les administrateurs SharePoint ne sont pas toujours familiers à SQL et vice versa.
Depuis SharePoint 2010, il est possible d’utiliser pour les bases de données, du mirroring SQL (mise en miroir de base de données). Ceci permet de faire en sorte que votre ferme soit plus tolérante à la panne et facilite aussi les maintenances.
Le principe est simple SharePoint utilise principalement une instance SQL pour ses bases de données et lorsque cette instance n’est pas disponible, il contacte l’instance de secours, le mécanisme est transparent et automatique et ne provoque pas d’interruption de service côté utilisateur final.
Les instances (PARTNERS) quant à elles se chargent de synchroniser les copies de bases de données et d’élire le serveur principal. Par exemple, si vous redémarrez un serveur, l’instance sait qu’elle va s’arrêter et prévenir l’autre instance qui héberge la copie pour qu’elle passe en instance principale. Autre cas de figure, si un de vos serveurs crash, l’autre prend le relais. Vous pouvez aussi demander la bascule manuellement.
Notes : La base de données « active » ou principale apparaitra normalement dans SQL Management Studio, celle « en attente » (la copie donc) apparaitra comme une base de données en restauration. Une troisième instance de WITNESS (témoin) peut être utilisée pour « surveiller » l’activité des deux autres et « piloter » les communications. Ce n’est pas obligatoire mais cela permet une meilleure fiabilité.
Comment cela fonctionne ? Le but de cet article n’est pas de faire un howto, deux articles (en anglais) le font très bien (un pour la partie SQL et un pour la partie SharePoint). Le but ici est d’indiquer l’idée générale du concept et de vous parler de certains pièges.
https://www.sharepointbandit.com/2010/08/configure-database-mirroring-on.html
https://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=202
Remarque, pour la mise en miroir des bases de données, après avoir créé les endpoints, j’ai préféré utiliser l’assistant graphique de SQL Management Studio depuis la base de données principale, c’est plus simple et plus rapide.
Pour revenir au fonctionnement de la mise en miroir, vous verrez que la procédure vous demande de passer les bases de données en « recovery mode : full ». Le fait de passer la méthode de récupération des données à « complet » implique que pour la base de donnée concernée, l’instance SQL va conserver l’INTEGRALITE des logs transactionnels sans JAMAIS les vider, et ce même si elle n’en a plus besoin. (Ceci permet de retracer et éventuellement de pouvoir rejouer toutes les requêtes jouées depuis)
Le problème étant que SharePoint est sans cesse en train d’exécuter des requêtes SQL, même quand il ne se passe « rien », ainsi on arrive vite à remplir un disque dur et à dégrader les services SharePoint.
Pas de panique deux solutions s’offrent à vous :
Tout n’est pas encore perdu : dans ce cas un backup des logs transactionnels, permet de les archiver. Les bests pratices vous demandent de les garder à vie pour avoir plus de chances de restaurer la base de données en cas de sinistre à partir de n’importe quel (ancien ou non) backup de base. En fait, la partie archivée des logs correspond à la partie dont SQL Server n’a plus besoin pour l’exploitation courante de la base de données. Les logs seront ainsi tronqués, la partie tronquée archivée et compressée dans un fichier de backup, libre à vous de le supprimer ou de le stocker ailleurs pour faire de la place.
Le disque est déjà plein : Dans ce cas basculez la base de données sur l’instance principale si elle n’est pas déjà en condition normale. Arrêtez la mise en miroir de la base. Supprimez la copie en restauration. Passez la base principale en mode de récupération Simple. Effectuez une compression (SRHINK) de la base de données si sa taille ne s’est pas réduite automatiquement. Repassez là en mode complet de récupération Complet et remontez la mise en miroir.
L’avantage avec cette seconde astuce c’est qu’elle n’interrompt même pas le service (car vous avez basculé sur l’instance principale) et qu’elle ne nécessite pas d’espace disque supplémentaire pour créer le backup des logs.
Attention tout de même, ceci est une méthode de secours, l’idéal reste encore de faire des backups des logs régulièrement.
Ce qu’il faut retenir pour résumer :
Le mirroring de bases pour SharePoint, c’est très pratique
Attention tout de même SharePoint étant gourmand en termes d’activité de la base de données, les disques durs risquent de se remplir vite avec des fichiers de logs
Les limites de fichiers de base de données ne fonctionnent (ou du moins ne permettront pas à votre ferme de fonctionner correctement lorsque les limites seront atteintes) pas puisque en mode de récupération complet (nécessaire à la mise en miroir), SQL Server conserve les logs transactionnels
Pour éviter les ennuis pensez à faire des backups régulièrement des fichiers de logs transactionnels.
Si le disque est déjà plein utilisez cette astuce, mais seulement dans ce cas-là.
A titre d’exemple, en 2 mois d’activité d’une ferme de taille moyenne de tests, la base de données de configuration est montée à plus de 20Go (dont plus de 19Go de logs transactionnels)