Guys,
We are going to do some changes to the way we are actually storing data on
the disk.
In particular, we are moving things so we would have less reliance on
system culture settings (more freedom to move things around), increased
document key size, etc.
After looking at what we want, I don't think we can do this sort of update
in place, and it would means that upgrading from 1.0 to 1.2 would be an
import / export operation, and now an in place upgrade like we had for 1.0
After looking at what we want, I don't think we can do this sort of update
in place, and it would means that upgrading from 1.0 to 1.2 would be an
import / export operation, and *not* an in place upgrade like we had for 1.0
On Mon, Apr 30, 2012 at 8:15 AM, Oren Eini (Ayende Rahien) <
aye...@ayende.com> wrote:
> Guys,
> We are going to do some changes to the way we are actually storing data on
> the disk.
> In particular, we are moving things so we would have less reliance on
> system culture settings (more freedom to move things around), increased
> document key size, etc.
> After looking at what we want, I don't think we can do this sort of update
> in place, and it would means that upgrading from 1.0 to 1.2 would be an
> import / export operation, and now an in place upgrade like we had for 1.0
NP from me. (But i don't have any live systems running).
Could we get some preliminary timings (with the standard disclaimers of course .. ie. on my crappy laptop, etc..) for the process, like using the music database u downloaded?
Just so we can all plan on some downtime and have some initial rough guestimates.
(of course, people will practice the procedure, before .. which will give them accurate timings..)
> NP from me. (But i don't have any live systems running).
> Could we get some preliminary timings (with the standard disclaimers of
> course .. ie. on my crappy laptop, etc..) for the process, like using the
> music database u downloaded?
> Just so we can all plan on some downtime and have some initial rough
> guestimates.
> (of course, people will practice the procedure, before .. which will give
> them accurate timings..)
IMO, nope. Ayende gave us some stats when he improved the Indexes a few weeks back. Disclaimers and all.
It wasn't so much the numbers then, it was more a percentage.
at least now we could get an idea that on a XXX machine, export took 1 hour, import 1 1/2 hours or whatever. and then related that to our own hardware: Oh! my hardware is just a wee bit more modern ... so lets say it will probably be a wee bit better but not too much. So now i know that if it takes more than 30 mins .. don't freak out.
What Ever makes RavenDB better, is a welcome change and thank you in advanced for it,
i think best solution for migration is to set a temporary new IIS RavenDB on different Port, then use Export/Import to work things out then just turn off the old Raven Server and things will work smooth right ?
Changing the backup (or smuggler) to allow it to backup to another
raven instance would be useful in this case...
Actually, it'd be useful in a lot of cases, I suspect :)
Or maybe replication would work for this? Replicate to the new one,
wait for it to finish, turn off the old one, use the new one?
On Mon, Apr 30, 2012 at 12:54, devmo...@hotmail.com
<devmo...@hotmail.com> wrote:
> What Ever makes RavenDB better, is a welcome change and thank you in
> advanced for it,
> i think best solution for migration is to set a temporary new IIS RavenDB
> on different Port, then use Export/Import to work things out then just turn
> off the old Raven Server and things will work smooth right ?
Earnest: Self-employed? Track your business expenses and income.
http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
On Mon, Apr 30, 2012 at 10:16 AM, Justin A <jus...@adler.com.au> wrote:
> NP from me. (But i don't have any live systems running).
> Could we get some preliminary timings (with the standard disclaimers of
> course .. ie. on my crappy laptop, etc..) for the process, like using the
> music database u downloaded?
> Just so we can all plan on some downtime and have some initial rough
> guestimates.
> (of course, people will practice the procedure, before .. which will give
> them accurate timings..)
> Wouldn't that be too hardware dependant to be of any use?
> On Apr 30, 2012 8:16 AM, "Justin A" <jus...@adler.com.au> wrote:
>> NP from me. (But i don't have any live systems running).
>> Could we get some preliminary timings (with the standard disclaimers of
>> course .. ie. on my crappy laptop, etc..) for the process, like using the
>> music database u downloaded?
>> Just so we can all plan on some downtime and have some initial rough
>> guestimates.
>> (of course, people will practice the procedure, before .. which will give
>> them accurate timings..)
On Mon, Apr 30, 2012 at 3:22 PM, Nic Wise <n...@fastchicken.co.nz> wrote:
> Changing the backup (or smuggler) to allow it to backup to another
> raven instance would be useful in this case...
> Actually, it'd be useful in a lot of cases, I suspect :)
> Or maybe replication would work for this? Replicate to the new one,
> wait for it to finish, turn off the old one, use the new one?
> On Mon, Apr 30, 2012 at 12:54, devmo...@hotmail.com
> <devmo...@hotmail.com> wrote:
> > What Ever makes RavenDB better, is a welcome change and thank you in
> > advanced for it,
> > i think best solution for migration is to set a temporary new IIS RavenDB
> > on different Port, then use Export/Import to work things out then just
> turn
> > off the old Raven Server and things will work smooth right ?
> Earnest: Self-employed? Track your business expenses and income.
> http://earnestapp.com > Nearest Bus: find when the next bus is coming to your stop.
> http://goo.gl/Vcz1p > mobileAgent (for FreeAgent): get your accounts in your pocket.
> http://goo.gl/IuBU > Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa > London Bike App: Find the nearest Boris Bike, and get riding!
> http://goo.gl/Icp2
On 30.04.2012 07:15, Oren Eini (Ayende Rahien) wrote:
> After looking at what we want, I don't think we can do this sort of update
> in place, and it would means that upgrading from 1.0 to 1.2 would be an
> import / export operation, and now an in place upgrade like we had for 1.0
This is going to be hard. An export/import can potentially take hours. Wouldn't it be possible to at least avoid to re-index all docs or will the index storage change as well?
On Tue, May 1, 2012 at 10:08 AM, Tobi <listacco...@e-tobi.net> wrote:
> On 30.04.2012 07:15, Oren Eini (Ayende Rahien) wrote:
> After looking at what we want, I don't think we can do this sort of update
>> in place, and it would means that upgrading from 1.0 to 1.2 would be an
>> import / export operation, and now an in place upgrade like we had for 1.0
> This is going to be hard. An export/import can potentially take hours.
> Wouldn't it be possible to at least avoid to re-index all docs or will the
> index storage change as well?
> Yes, there are going to be fixes to 1.0 as needed for at least 18 months
> after the 1.2 release.
> We can't avoid re-indexing, because one of the things that we are changing
> it the actual on index format (for things like dates, for example.
> On Tue, May 1, 2012 at 10:08 AM, Tobi <listacco...@e-tobi.net> wrote:
> > On 30.04.2012 07:15, Oren Eini (Ayende Rahien) wrote:
> > After looking at what we want, I don't think we can do this sort of update
> >> in place, and it would means that upgrading from 1.0 to 1.2 would be an
> >> import / export operation, and now an in place upgrade like we had for 1.0
> > This is going to be hard. An export/import can potentially take hours.
> > Wouldn't it be possible to at least avoid to re-index all docs or will the
> > index storage change as well?
> On May 1, 8:50 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com<javascript:;>
> wrote:
> > Yes, there are going to be fixes to 1.0 as needed for at least 18 months
> > after the 1.2 release.
> > We can't avoid re-indexing, because one of the things that we are
> changing
> > it the actual on index format (for things like dates, for example.
> > On Tue, May 1, 2012 at 10:08 AM, Tobi <listacco...@e-tobi.net<javascript:;>>
> wrote:
> > > On 30.04.2012 07:15, Oren Eini (Ayende Rahien) wrote:
> > > After looking at what we want, I don't think we can do this sort of
> update
> > >> in place, and it would means that upgrading from 1.0 to 1.2 would be
> an
> > >> import / export operation, and now an in place upgrade like we had
> for 1.0
> > > This is going to be hard. An export/import can potentially take hours.
> > > Wouldn't it be possible to at least avoid to re-index all docs or will
> the
> > > index storage change as well?
