Hi, Another way is just dump the database and upload it in the another bd (If you are using postegres): => http://www.postgresql.org/docs/9.4/static/app-pgdump.html
1th server pg_dump > $HOME/exports/dspace-export-to-another-server.sql 2th server shutdown the tomcat dropdb -U dspace "name of Dspace_DB" createdb -U dspace -E UNICODE "name of Dspace_DB" -T template0 psql -U dspace "name of Dspace_DB" < exports/dspace-export-to-another-server.sql startup the tomcat You can even use the rsync to copu the file from one server to another. On Thu, Jul 30, 2015 at 2:14 AM, Kosmas Kaifel <kosmas.kai...@uni-ulm.de> wrote: > Hi, > > I think the best way in this case is you export the whole database from > server A > and import this export into server B. > You can do this wiht tools from the DB-Developer. > > Nice greatings Kosmas > > Am 29.07.2015 um 15:33 schrieb Mark H. Wood: > > On Wed, Jul 29, 2015 at 01:46:00PM +0300, Mansoor Ali wrote: > > Iam really thankful if any one would help me in this case. > > Iam trying this to implement on windows. > I want to create two instances for dspace-5.2-src-release and to keep both > the instances in two different servers called ServerA & ServerB and my main > intention is to view the same data from both instances so please any body > have a solution for this case or what will be the best way to view the same > data from two instance which are on two different Servers and these two > servers are connected to a single DB server & a single assetstore. > > I have not tried to build such a system, but here is what I would do. > > The two instances of DSpace should in this case use a single database, > not two separate databases. That is: db.url should be the same for > both. > > The shared assetstore should be in a filesystem that can coordinate > concurrent use across a cluster of hosts and is configured to do so. > It appears to me that you are running your DSpaces on MS Windows, and > I haven't touched a Windows server in years so I don't have any good > specific advice on that. > > The behavior that you see with two separate databases, even though > stored in the same DBMS instance, is what I would expect. The > database is how DSpace knows what it has and where to find it. > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > DSpace-tech mailing > listDSpace-tech@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/dspace-tech > List Etiquette: > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette > > > -- > +---------------------------------------------------------------+ > Universität Ulm > Kommunikations- und Informationszentrum (kiz) > Abt. Infrastruktur > Albert-Einstein-Allee 37 > 89081 Ulm > Tel. 0731/50-15495 > EMail: kosmas.kai...@uni-ulm.de > +----------------------------------------------------------------+ > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech > List Etiquette: > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >
------------------------------------------------------------------------------
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette