I am planning with backups, the recovery will only be incremental. Is there an internal field to know when the last document hit the index or is this best to build your own "created_at" type field to know when you need to rebuild from?
After the backup is restored, this field could be read and then the restore from that time could kick in. On Wed, Jan 28, 2009 at 4:34 PM, Feak, Todd <todd.f...@smss.sony.com> wrote: > Although the idea that you will need to rebuild from scratch is > unlikely, you might want to fully understand the cost of recovery if you > *do* have to. > > If it's incredibly expensive(time or money), you need to keep that in > mind. > > -Todd > > > -----Original Message----- > From: Ian Connor [mailto:ian.con...@gmail.com] > Sent: Wednesday, January 28, 2009 12:38 PM > To: solr > Subject: solr as the data store > > Hi All, > > Is anyone using Solr (and thus the lucene index) as there database > store. > > Up to now, we have been using a database to build Solr from. However, > given > that lucene already keeps the stored data intact, and that rebuilding > from > solr to solr can be very fast, the need for the separate database does > not > seem so necessary. > > It seems totally possible to maintain just the solr shards and treat > them as > the database (backups, redundancy, etc are already built right in). The > idea > that we would need to rebuild from scratch seems unlikely and the speed > boost by using solr shards for data massaging and reindexing seems very > appealing. > > Has anyone else thought about this or done this and ran into problems > that > caused them to go back to a seperate database model? Is there a critical > need you can think is missing? > > -- > Regards, > > Ian Connor > -- Regards, Ian Connor 1 Leighton St #723 Cambridge, MA 02141 Call Center Phone: +1 (714) 239 3875 (24 hrs) Fax: +1(770) 818 5697 Skype: ian.connor
