On Tue, Feb 3, 2009 at 2:19 PM, Kiran Ayyagari <[email protected]>wrote:
> > Hi Alex, > > I'm seriously thinking the use of the CL for a journal is not a good >> decision. The journal needs to be fast and simple, doing only one thing and >> doing it fast and flawlessly. >> > +1, by 'replica of CL' I mean the journal contains the same data what CL > stores in its store minus the indices and journal just writes that data in a > sequential order (CL could be a B-Tree). Right I agree the CL is fine as it is with the B-Tree and indices. The journal need not be a btree if all we need is sequential access. We merely need a simple pointer or two into it to know where the last operation was successfully processed. Hence everything earlier or after it in the file represents currently active operations. > > However an assumption I made here was that each valid operation succeeds at > least before storing its data in CL > ( we have to write the same data to journal before storing in CL) this way > we no longer need any marking operation cause > if the master db gets corrupted we use CL to restore and if the CL also > gets corrupted then we can restore the CL from > journal(start from the beginning hence no intermediate 'marks') and then > restore the master db. > I agree that *ONLY* change operations that have succeeded should be logged into the CL. But I think we at least need a marker in the journal to track the horizon between completed and in progress operations no? Alex
