[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] [Bacula-users] Proplem upgrading from 1.38 to 2.2
Well upgrading from 1.38 to 2.2 is a non-trivial exercise since the database
was upgraded several times between the two versions, and unless you first
upgraded to Bacula 2.0, then did a second update to 2.2, I am not sure that
the Debian upgrade will get everything right -- I imagine that is why you did
it from source, and if your Bacula is running, then it looks like things went
more or less OK.
Yes, if you want to turn batch insert off, you either have to run ./configure
with the appropriate options (the preferred way), or you must comment the
#define out. Commenting out the #define is the way the autoconf system
works -- it is nothing Bacula specific.
Concerning your problems when running Batch insert enabled, I suspect that you
have a bad build or a bad version the MySQL libraries. For batch insert to
work, Bacula needs the thread safe version of the MySQL development libraries
(mysql-xxx_r.so) -- if they are not there, normally, it should not build, but
since I don't have the details of your build, I cannot say for sure.
I can assure you that Batch insert does work -- it is enabled by default, and
we have had very few complaints about it -- most of the have to do with an
inadequate MySQL/PostgreSQL configuration (i.e. not tuned to have sufficient
memory resources). I believe these points are mentioned in the manual, and
possibly the release notes, but I have to say that if I were personally
upgrading from 1.38 to 2.2, I would probably have missed them ...
If you either send me an attachment with your "comments" or point me to an
exact link to the thread, we'll at least take a quick look at it for anything
that might stand out. Sorry, I no longer have the time to search for such
things :-( I think Eric might be interested in this too since batch insert
is mostly his baby :-)
See a couple notes below ...
On Saturday 17 May 2008 07:06:34 Jari Fredriksson wrote:
> >> I running bacula server on a Debian Etch.
> >> I upgraded via www.backports.org and now...
> > Is it normal, that MySQL runs at 100% processor "hours"
> > after a backup? Maybe 1st time after an upgrade from
> > 1.38?
> > Image: http://www.localnet.fi/jarif/images/bacula_100.png
> Everything seems to work now. I had to download latest bacula source
> tarball, edit src/config.h so that
> #define HAVE_BATCH_FILE_INSERT 1
> /* #define HAVE_BATCH_FILE_INSERT 1 */
> (You have to comment it out, defining it as 0 does not work!)
> And voila! My MySQL is happy and back up works.
> HAVE_BATCH_FILE_INSERT seems to be so wrong in so many levels, that it's
> best to disable.
> My setup:
> # mysql --version
> mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using
> readline 5.2
My setup here is:
$ mysql --version
mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline
with Batch insert on. Naturally, I always build from source :-)
> # uname -a
> Linux wellington 2.6.22-4-686 #1 SMP Tue Feb 12 16:29:32 UTC 2008 i686
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/hda3 298G 93G 206G 32% /
> tmpfs 125M 0 125M 0% /lib/init/rw
> udev 10M 56K 10M 1% /dev
> tmpfs 125M 0 125M 0% /dev/shm
> /dev/hda1 30M 14M 15M 48% /boot
> # free -m
> total used free shared buffers cached
> Mem: 249 215 34 0 49 45
> -/+ buffers/cache: 119 129
> Swap: 243 44 198
> All went wrong when I upgraded from Bacula 1.38 to 2.2.8
> (www.backports.org), but now that I did it with source and that "unsetting"
> of the BATCH handling, my system works.
> You can find some more comments (although not all constructive) on that
> BATCH SQL handling in this thread of mine, have a look or not.
> I have noticed positive things in Bacula in this upgrade as well. My tape
> sometimes mounts as READ-ONLY, and bacula used to fail jobs when that
> happened. 2.2.x seems to handle that, altought not perfecktly. It seems to
> mount the tape, and says "Thank You" but nothing happens. Unmounting and
> remounting after "mt status" it's happy and the backup continues. That is
> much better than in 1.38 where a 10 tape backup failed because #11 tape was
> read only!!
> Thanks for all participants for this great software!
Thanks for the thanks -- especially after the problems you had.
> Regards, jarif (Happy camper now!)
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.