1 |
I was planning on updating a client from Mysql 3.23 to Mysql 4.0, but |
2 |
since 4.1 has stabilized I figured I'd give it a shot. And I'd also be |
3 |
able to move another client off their crappy db server on the new shared |
4 |
server if it had 4.1. However my setup has a few quirks. |
5 |
|
6 |
The 3.23 install is acting for the replication master for the 4.0 |
7 |
install on the new server. The client is testing with 4.0 and everything |
8 |
looks good. Ideally I'd like to stop replication, dump the db, upgrade |
9 |
to 4.1, import the db, and start replication again. 4.1 can replicate |
10 |
from 3.23, but I'm unsure if it can pick up where 4.0 left off. Has |
11 |
anyone tried this? It's not the end of the world if it explodes in my |
12 |
face, but I would keep up with my sleep by skipping another late night |
13 |
maintenance to do a fresh dump from the master to restart replication |
14 |
correctly. |
15 |
|
16 |
The other question is about libs. I'm looking at a project that will |
17 |
likely use Mysql 5.0 on the server side. At what point do I need to |
18 |
update the client libs... or can I just use Mysql 4.0 libs in PHP and |
19 |
whatnot till Redhat updates their builds? Some sort of checklist, Google |
20 |
has been not helped so far, explaining when a client build would need to |
21 |
be updated would be keen. Again not the end of the world, but I'd rather |
22 |
not be building a bunch of custom packages if I can help it. |
23 |
|
24 |
kashani |
25 |
-- |
26 |
gentoo-user@g.o mailing list |