List:Commits« Previous MessageNext Message »
From:anders Date:January 25 2011 6:51am
Subject:Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925
View as plain text  
Hi Daogang,

[snip]
> >>      
> >>> 3. Isn't there any race condition between rotation and pre-allocation?
> >>>
> >>>      server --->   decides to use master.X
> >>>
> >>>      mysqlbinlogalloc --->   creates master.X
> >>>
> >>>      server --->   fails while creating master.X (booom)
> >>>        
> > Not sure if it will fail, but this case exists, I think.
> > A way to avoid this case is that mysqlbinlogalloc create the file with a
> > temporary name and then rename it.
> >    
> This case is not exist. Because we assumed that user just can
> do statical preallocation  when server is off. The automatic
> preallocation will be used  when server is on.  I think we should
> design to forbid user from doing statically preallocation when
> server is on. Maybe just documentation is not enough. What
> do you think?
It is not convenient if user can preallocation the binlog file only when
server is off. I don't think users can plan all things well before
starting the server. So let us make the facility more convenient.
> >>>
> >>>        
> >> No. Static and automatic preallocation are compatible. One will not
> >> preallocate the file if another is a preallocating it. So no conflict here.
> >>      
> > [snip]
> >    
> >>      
> >>> 4. Using the binlog_preallocate to decide if either the old or new
> behavior should
> >>>      be used is not a good idea. We may pre-allocate files and start the
> server with
> >>>        binlog_preallocate<>   0 and then forget and restart the
> server with binlog_preallocate
> >>>      = 0. In this case, we are going to have dangling files consuming
> lots of disk space.
> >>>
> >>>      If We can I think we must avoid situations where an user's mistake
> may cause problems.
> >>>
> >>>        
> >> Maybe. But how to avoid this?
> >>      
> >    
> >>> 5. Using binlog_preallocate>   1 to automatically pre-allocate binary
> log files is not
> >>>      a good idea because users will not have control when the
> pre-allocation will happen.
> >>>      See item 1.
> >>>
> >>>        
> >> I don't think the user should control something in the process as it's a
> >> automatic preallocation.
> >>      
> >>> 6. Why do you need to keep the old behavior where new files are created
> after searching
> >>>      in the filesystem? I know that this done just for safety in order
> to avoid overwriting
> >>>      a possible useful binary log. However, this case will only happen
> if someone manually
> >>>      copies files around.
> >>>
> >>>        
> >> The old behavior is good. It can guarantee that Static and automatic
> >> preallocation are compatible.
> >>      
> >>>      Besides, we have committed several patches towards making the index
> file the source
> >>>      of truth. So why don't we keep just the new behavior where the
> index file is the source
> >>>      of truth?
> >>>
> >>>      If overwriting a file is really a concern. I think we should use
> two states in the
> >>>      binary log:
> >>>        . LOG_EVENT_BINLOG_IN_USE_F
> >>>        . LOG_EVENT_BINLOG_PRE_ALLOC
> >>>
> >>>      So, if the new file is pre-allocated, its status would be
> LOG_EVENT_BINLOG_PRE_ALLOC
> >>>      and the server would be able to know if it is safe to overwrite it
> or not.
> >>>
> >>>        
> > I agree with Alfranio. binlog_preallocate is not necessary.
> > There are other ways that can keep the both behaviors.
> > 1. Just like Alfranio said.
> > 2. Use a new BINLOG_MAGIC
> > 3. Add a prefix in the file name.
> >     /mysqlbinlogalloc  --start=1 --end=10 --alloc-size=2G
> --binlog-name=mysql-binlog
> >
> > pre-mysql-binlog.000001 .. pre-mysql-binlog.000010 are generated.
Add a prefix is convenient to users too. Users is easy to know and
manage these files.
> >
> > When server need a new binlog file, it will try to find a
> > pre-mysql-binlog.* and rename it to a regular binlog name.
> >
> > I prefer 3.
> >    
> The number 3 just can handle the case of static preallocation if 
> binlog_preallocate is not
> used. But it can't support automatic preallocation. In fact static 
> preallocation just is a assistant
> tool.
> 
> I persist to use binlog_preallocate for providing more choice for users 
> and meet different
> requirement from users.
> 
"- if binlog_preallocate >= 1, creating and preallocating more binlog
files. The
number of preallocated binlogs are equivalent to binlog_preallocate
value."
I think it is not necessary to pre-allocate more than one file when
server needs a new binary log file.
So binlog_preallocate = 0 means server doesn't pre-allocate space for
binary log file.
binlog_preallocate = 1 means server pre-allocates space for binary log
file.

Server should use pre-allocated binary log file if there are some,
whenever binlog_preallocate is 0 or 1. In this way, mysqlbinlogalloc can
be used when servers are on.


-- 
Your Sincerely, 
Libing Song
==================================
MySQL Replication Team
Software Engineer


Email : Anders.Song@stripped
Skype : libing.song
MSN   : slb_database@stripped
Phone : +86 010-6505-4020 ext. 319
Mobile: +86 138-1144-2038
==================================

Thread
bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925daogang.qu5 Jan
  • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Alfranio Correia21 Jan
    • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Daogang Qu24 Jan
      • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Luís Soares24 Jan
      • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925anders24 Jan
        • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Alfranio Correia24 Jan
          • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Daogang Qu25 Jan
        • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Daogang Qu25 Jan
          • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925anders25 Jan
            • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Daogang Qu25 Jan
              • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925anders25 Jan
                • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Daogang Qu25 Jan
          • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Alfranio Correia25 Jan
      • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Alfranio Correia24 Jan
        • Re: bzr commit into mysql-trunk branch (daogang.qu:3446) WL#4925Daogang Qu25 Jan