Neil Gunton wrote: > > Since I didn't get any replies to my previous message (see below), I am > trying to compile MySQL myself, to see if it results in a more stable > system when using replication. However this is failing consistently with > the following error: > > make[4]: Entering directory `/usr/src/mysql-4.0.17/sql' > source='sql_lex.cc' object='sql_lex.o' libtool=no \ > depfile='.deps/sql_lex.Po' tmpdepfile='.deps/sql_lex.TPo' \ > depmode=gcc3 /bin/sh ../depcomp \ > gcc -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr/local/mysql\"" > -DDATADIR="\"/usr/local/mysql/var\"" > -DSHAREDIR="\"/usr/local/mysql/share/mysql\"" -DHAVE_CONFIG_H -I. -I. > -I.. -I../innobase/include -I./../include -I./../regex -I. -I../include > -I. -O3 -DDBUG_OFF -fno-implicit-templates -fno-exceptions > -fno-rtti -DUSE_MYSYS_NEW -DDEFINE_CXA_PURE_VIRTUAL -c -o sql_lex.o > `test -f sql_lex.cc || echo './'`sql_lex.cc > sql_lex.cc: In function `void lex_init()': > sql_lex.cc:85: `symbols' undeclared (first use this function) > sql_lex.cc:85: (Each undeclared identifier is reported only once for > each > function it appears in.) > sql_lex.cc:87: `sql_functions' undeclared (first use this function) > sql_lex.cc: In function `int find_keyword(LEX*, unsigned int, bool)': > sql_lex.cc:171: `get_hash_symbol' undeclared (first use this function) > > I have tried this with the gcc compiler that comes with RedHat 7.3 > (2.96), and also with gcc 3.2.3 (built from source, because of the > advice on the MySQL website that says 2.96 might be unstable). I tried > building 2.95 from source, but it didn't seem to be able to recognize my > system and I couldn't see from the documentation how to fix this. > However given that 2.96 (rpm) and 3.2.3 (src) both give exactly the same > result, I wouldn't have high hopes for 2.95. I have tried several > different invocations for ./configure, including the following three: > > ./configure --prefix=/usr/local/mysql > > CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc CXXFLAGS="-O2 -mcpu=pentiumpro > -felide-constructors" ./configure --prefix=/usr/local/mysql > --with-extra-charsets=complex --enable-thread-safe-client > --enable-local-infile --enable-assembler --disable-shared > --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static > > CXX=gcc ./configure --prefix=/usr/local/mysql > --with-extra-charsets=complex --enable-thread-safe-client > --enable-local-infile --disable-shared > > The latter two were from section 2.1.2.5 of the MySQL manual. > > Searching google for the error message I can see that other people have > had a similar problem with this, but I have seen no solutions. Does > anyone have the secret incantation to successfully build MySQL 4.0.17? > > I fully realize that MySQL AB recommends using the binary rpms supplied > by them, but since I am having no luck with finding out what's wrong > with replication, I think it makes sense to try and build it myself and > see if that makes any difference. > > Any advice much appreciated...
Further to the above problem, I eventually found a clue in the "internals" mailing list archives for MySQL: http://lists.mysql.com/internals/7702 I found that I could go into the sql directory and manually make gen_lex_hash, and then generate lex_hash.h by hand: Starting in the main MySQL source build directory, shell> cd sql shell> make gen_lex_hash shell> ./gen_lex_hash > lex_hash.h shell> cd .. shell> make This seemed to make it work, and the compile then finished successfully. Since then I have upgraded to the latest gcc 3.3.2 (built from source), and rebuilt on both my server and my workstation - and, for some reason, this time around the build went without error on the workstation, even having deleted and re-unpacked the MySQL source directory (i.e. no chance of the manual makes being left over from before). I don't know what's different this time around, a real mystery there! I built using the first example config given in the MySQL docs: CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc CXXFLAGS="-O2 -mcpu=pentiumpro -felide-constructors" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --disable-shared --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static I also found I had to add /usr/local/lib to /etc/ld.so.conf (and then do ldconfig) in order for certain so libs in the new gcc to be found. On my workstation, I found I had to set socket=/var/lib/mysql for both mysqld and client in my.conf, because for some reason Perl DBI (in mod_perl) was looking for it there, whereas MySQL was creating it in /tmp/. Strangely, I didn't have to make this tweak on my server, which is strange since they both run pretty standard Red Hat 7.3 installations. Obviously something is different, but I don't know what. On the workstation, at any rate, it was enough to throw off the 'make' process for MySQL, and it's not just me - I found quite a few references on google to problems building sql_lex.cc. It must be some sort of special case, but I'm afraid I just don't know what. In any case, I've now been running with the new rebuilt MySQL 4.0.17 for the last couple of days without any problem with the replication (see below for original message detailing the problems I was having). Since I am no longer getting 'out of sync' conditions on the slave, nor any lost updates on the master, I can only assume that building from source was in this case a good solution. I just thought this might be useful to anyone else out there who's encountered the same situation - either with replication, lost updates, or building from source for some other reason. If you're getting instabilities and weird behavior in the production version of MySQL, it might be worth building from source just to see how it affects the problem - for me it certainly seemed to improve matters. -Neil > Neil Gunton wrote: > > > > I am using 4.0.17 rpm on Red Hat 7.3 (fully updated). I have a server > > colocated at my local ISP, and my workstation is on ADSL behind a Netsys > > router (the ADSL ISP uses PPPoE, don't know if that's relevant or not). > > The server has RAID 1, and has always been 100% reliable (up since > > 2000). I have been using MySQL for over four years now, and have never > > had any problems until recently, when I tried using replication. > > > > I wanted to mirror the database to my workstation over the DSL > > connection. I got it working correctly, but quickly found that the slave > > would just stop replicating if I went away and left it for a while > > (hours). It would be fine while I sat there, but overnight or after a > > couple of hours away from my workstation, I would return and it had just > > stopped. There were no errors in the log on either end. It just wasn't > > updating. Restarting the slave would quickly bring things up to date > > again. Eventually I tried lowering the master-connect-retry to 10 > > seconds, and slave-net-timeout to 60 seconds. This seemed to fix this > > particular problem. Overnight I could come back and everything was still > > synced up. I don't know why this could cause an issue, since I keep > > long-lived ssh connections to my server all day long without problem. > > > > I have also noticed other problems - most worrying of which is that > > records inserted into the master database have actually disappeared > > completely from the master and slave. My website has message boards, and > > on two occasions now I have posted a message, seen it in the database > > (i.e. read the website) and then come back to see that the new message > > is just gone. These boards have been in operation for years, and are > > extremely reliable. Never have messages simply vanished. The first time > > this happened, it only took a few seconds to go away. The second time, > > it was overnight. This is extremely scary behaviour. > > > > Also, in multiple unrelated instances, one of the master index files > > have become corrupted, and had to be repaired using myisamchk. All my > > tables are MyISAM. The same corruption has also happened on the slave. I > > have never had corrupted tables before now. > > > > The other thing that keeps happening is that the slave seems to get out > > of sync somehow with the master - I came in this morning to find that it > > had choked on a duplicate primary key. I made the slave skip 2 and it > > recovered itself, but this has happened a number of times now. There is > > no work being done on the slave version of the database, no possible way > > that it would get out of sync as a result of changes on the workstation. > > I am the only user, and there are no processes doing anything with the > > database. It is a pure slave. Yet, somehow, it ends up with a duplicate > > key. > > > > I am worried enough about all this that I have disabled replication for > > the time being. > > > > Has anyone else experienced missing updates and/or table index > > corruption as a result of enabling replication? The replication > > mechanism should surely "do no harm" on the master as a result of being > > active, but this is clearly happening. I am fairly sure that this is a > > bug, but since it is so sporadic and non repeatable, it's very hard to > > say what could be causing it. I should make clear that I am fairly > > certain that replication is set up correctly - it replicates very well > > in normal circumstances. Updates on the server appear on the slave > > almost instantaneously. > > > > If anyone else has any insight or similar experiences, please let me > > know. I would like to know if this is a "known bug" or something that > > hasn't been nailed down yet. > > > > I should finally say that I've always been 100% happy with the > > robustness of MySQL, so this was a little shocking to me! I think MySQL > > is an extremely useful database system, and I plan to continue using it. > > Hopefully all this is just an obscure bug. > > > > Thanks, > > > > -Neil Gunton > > > > -- > > MySQL General Mailing List > > For list archives: http://lists.mysql.com/mysql > > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
