Discussion :

[MacPro]

Bonjour,

Je dispose de plusieurs machines (pas des PCs, des machines avec un OS Linux) qui tournent actuellement avec SQLite. En fonctionnement, ces machines enregistrent plein de paramètres en base de donnée.
Je voudrais les passer sur PostgreSQL car SQLite devient trop limité pour mon besoin.
Afin de faciliter la maintenance, je voudrais que chacune des machines puisse de temps à autre (la nuit, ou sur demande) aller sauvegarder son contenu sur une grosse base maître, contenu qui pourrait être restauré lors du remplacement d'une machine foutue.
Il arrive aussi qu'un utilisateur se serve de plusieurs machines et aimerait bien récupérer ses paramètres qu'il a déjà saisit sur d'autres machines.
Si je dois disposer d'un serveur centralisé sur lequel toutes les machines ont leur base répliquée/sauvegardée, la sauvegarde peut être programmée. Il est impératif que chaque machine puisse tourner indépendamment d'une autre et n'ait pas à attendre quoique ce soit pour enregistrer des données.
Enfin, j'ai besoin de pouvoir faire des statistiques globales par machine et/ou sur le parc de machines directement.

Questions :
* est-ce qu'il me faut un serveur central avec autant de bases que de machines ?

[alassanediakite]

Salut
Une seule BD sur le serveur suffit. Chaque machine enregistre ou lit ses paramètres en fonction de sont identifiant. Ceci t'évitera beaucoup de problèmes et donnera plus d'avantages (tels la sauvegarde unique, la conception unique).
@+

[MacPro]

Salut et merci pour ta réponse.

Une seule BD sur le serveur suffit

-> Je ne suis pas sûr que ça suffise car il faut que chaque machine dispose de sa propre base à elle, locale. Parfois, les machines sont vendues sans rien autour et unique, des "parcs" de une machine si tu préfère.
De plus, en fonctionnement, une panne réseau est intolérable. C'est une machine médicale et on ne peut pas se permettre de perdre des données lors du fonctionnement juste parce que le serveur ne répond pas pour une raison ou une autre.

[bizulk]

Je serais aussi pour l'idée du serveur de sauvegarde avec une seule base, ne serait qu'en regard de l'atomicité des transactions sur la base, et la sauvegarde unique des paramètres associés à un opérateur quelles que soit le nombre de machines sur lesquelles il travaille.
Par contre il te faudra effectivement reconstituer une base sur la machine, à partir des éléments récupérés depuis le serveur central.

Le risque de "perte" temporaire ou définitive de données est surtout lors du "transfert" d'une machine à l'autre des paramètres "user" :
si le serveur est indisponible tu ne peux effectivement actualiser la machine sur une ouverture de session, mais les données sont toujours disponibles sur l'autre machine. Dans ce cas la sécurisation peut se faire via la redondance de ton mécanisme de synchronisation : bêtement via une procédure de sauvegarde/restauration par un autre moyen, comme un fichier sur clé usb par exemple.

[SQLpro]

Bonjour,

Je dispose de plusieurs machines (pas des PCs, des machines avec un OS Linux) qui tournent actuellement avec SQLite. En fonctionnement, ces machines enregistrent plein de paramètres en base de donnée.
Je voudrais les passer sur PostgreSQL car SQLite devient trop limité pour mon besoin.
Afin de faciliter la maintenance, je voudrais que chacune des machines puisse de temps à autre (la nuit, ou sur demande) aller sauvegarder son contenu sur une grosse base maître, contenu qui pourrait être restauré lors du remplacement d'une machine foutue.
Il arrive aussi qu'un utilisateur se serve de plusieurs machines et aimerait bien récupérer ses paramètres qu'il a déjà saisit sur d'autres machines.
Si je dois disposer d'un serveur centralisé sur lequel toutes les machines ont leur base répliquée/sauvegardée, la sauvegarde peut être programmée. Il est impératif que chaque machine puisse tourner indépendamment d'une autre et n'ait pas à attendre quoique ce soit pour enregistrer des données.
Enfin, j'ai besoin de pouvoir faire des statistiques globales par machine et/ou sur le parc de machines directement.

Questions :
* est-ce qu'il me faut un serveur central avec autant de bases que de machines ?

Pour information (une solution qui ne va pas te plaire...), ce genre de chose est intégré dans certains SGBDR (sous forme SODA : Service Oriented Database Architecture) comme SQL Server dans lequel cela s’appelle "Service Broker". Dans tes machines tu met la version Express gratuite et les files d'attente de SB s’occupent automatiquement d'alimenter le serveur central en dialoguant de manière asynchrone et transactionnelle. Pour informations, c'est ce que nous avons mis en œuvre pour contrôler la chaine de fabrication des vaccins chez pasteur mérieux... Il y fallut juste 2 jours de mise en place et maintenant 1 minute pour toute nouvelle machine (c'est juste une restauration d'une base "matrice").

En savoir plus :
http://blog.developpez.com/sqlpro/p7...service_broker
https://technet.microsoft.com/en-us/...ql.105%29.aspx

Ceci vous évitera de développer des fonctionnalités finalement très complexes et peu fiables (pensez à ce qui risque de se passer en cas de coupure réseau ou arrêt pour maintenance du serveur principal...) et passer énormément de temps en reprise d'incident...


A +

[bizulk]

SQLPro tu me corrigeras s'il le faut,...

Tu peux effectivement utiliser un broker ou d'autres AMQP pour interfacer les bases.
Cela va fiabiliser les liaisons avec les queues messages.
Mais en terme de "haute disponibilité" je maintiens l'idée d'un second moyen plus "rétro" et plus indépendant

[MacPro]

Pour information (une solution qui ne va pas te plaire...), ce genre de chose est intégré dans certains SGBDR (sous forme SODA : Service Oriented Database Architecture) comme SQL Server dans lequel cela s’appelle "Service Broker". Dans tes machines tu met la version Express gratuite et les files d'attente de SB s’occupent automatiquement d'alimenter le serveur central en dialoguant de manière asynchrone et transactionnelle. Pour informations, c'est ce que nous avons mis en œuvre pour contrôler la chaîne de fabrication des vaccins chez pasteur mérieux... Il y fallut juste 2 jours de mise en place et maintenant 1 minute pour toute nouvelle machine (c'est juste une restauration d'une base "matrice").

En savoir plus :
http://blog.developpez.com/sqlpro/p7...service_broker
https://technet.microsoft.com/en-us/...ql.105%29.aspx

Ceci vous évitera de développer des fonctionnalités finalement très complexes et peu fiables (pensez à ce qui risque de se passer en cas de coupure réseau ou arrêt pour maintenance du serveur principal...) et passer énormément de temps en reprise d'incident...

A +

Bonjour,

merci de la réponse. Que ça me plaise ou pas, ce n'est pas tellement la question en fait. Nos machines sont sur base ARM, le tout sous linux ,donc les technos Microsoft ce n'est pas tout à fait possible dans notre cas.
Je précise que chacune de nos machines est indépendante de l'autre, une va peut-être servir uniquement couplée à des examens IRM, l'autre pour des rayons X. Dans tous les cas, le schéma de la base de chaque machine est identique mais les données varient en fonction du service où la machine se situe.
Entre chaque machine il peut cependant y avoir quelques données communes qu'un utilisateur de plusieurs services aimerait récupérer sans avoir à les saisir à nouveau.
En cas d'arrêt ou de coupure du serveur principal, je suppose qu'il y a un mécanisme qui est au courant qu'une sauvegarde a foiré.
Enfin, les machines n'ont pas vocation à dialoguer avec le serveur principal, les ressources sont limitées et une sauvegarde par nuit ça suffirait bien.

Toutefois, merci pour le SODA, je ne connaissais pas.

[SQLpro]

SQLPro tu me corrigeras s'il le faut,...

Tu peux effectivement utiliser un broker ou d'autres AMQP pour interfacer les bases.
Cela va fiabiliser les liaisons avec les queues messages.
Mais en terme de "haute disponibilité" je maintiens l'idée d'un second moyen plus "rétro" et plus indépendant

Service Broker ce n'est pas la même chose. Les éléments que tu présentent fonctionnent au niveau applicatif. Service broker ne travaille que de serveur SQL en serveur SQL et de base à base sur la couche de données. De plus c'est transactionné et sérialisé de manière native et par défaut crypté. Le tout est véhiculé dans des tables qui opèrent des files d'attente. Ce qui fait que la sauvegarde de la base emporte l'état des communications (persistées).

A +

[SQLpro]

Je précise que chacune de nos machines est indépendante de l'autre, une va peut-être servir uniquement couplée à des examens IRM, l'autre pour des rayons X. Dans tous les cas, le schéma de la base de chaque machine est identique mais les données varient en fonction du service où la machine se situe.

C'est bien ce que propose Service Broker qui va même plus loin, car chaque serveur SQL n'a pas l'obligation d'avoir la même architecture de base ni les mêmes tables. Les tables peuvent être différentes sur chaque base et aucune base ni aucun serveur n'est couplé à un autre serveur.

Entre chaque machine il peut cependant y avoir quelques données communes qu'un utilisateur de plusieurs services aimerait récupérer sans avoir à les saisir à nouveau.

Cela peut justement être réglé par Service Broker qui diffusera les données.

En cas d'arrêt ou de coupure du serveur principal, je suppose qu'il y a un mécanisme qui est au courant qu'une sauvegarde a foiré.

Service Broker repose nullement sur des sauvegardes qui doivent être faites en toute indépendance

Enfin, les machines n'ont pas vocation à dialoguer avec le serveur principal, les ressources sont limitées et une sauvegarde par nuit ça suffirait bien.

Le volume transitaire serait le même que vous véhiculiez un gros fichier ou que vous agissiez au fil de l'eau. L'avantage en revanche c'est qu'en cas d'indisponibilité du serveur principal, vous n'avez pas à attendre la nuit suivante pour la consolidation.

Toutefois, merci pour le SODA, je ne connaissais pas.

SODA permet de faire des architectures distribuées au niveau de la base de données. C'est du maillage de serveur qui peut aussi bien répartir la charge que les données, selon votre besoin...

A +

[MacPro]

Merci pour toutes ces réponses. Bon, j'avoue, je suis dans le même état mais j'aurais appris quelque chose quand même.