Hi, thanks Martin for the clarification, I have updated the http://wikis.sun.com/display/WebStack/MySQL64bitARC onepager reflecting this.
So changes are: -added amd64 and sparcv9 bin and lib directories containing the bits, and a softlink, 64, to the appropriate subdirectory. -moved the 64 bit binaries/libraries into existing packages. -SMF: Add a property for choosing 64 vs 32 bit, not adding an extra service. -Don't need extra data files directory for 64 bit. Jan S Martin MC Brown wrote: > Hi Peter, Jan, everyone, > >> Likewise, why have a different location for the data files? >> >> (A technical question - are the data files incompatible between >> 32 and 64 bit servers?) > > > All the current major storage engines (with one exception) are > architecture neutral, both in endian-ness and bit size. You should be > able to copy a 64-bit or 32-bit DB either way, and even between > platforms without problems for MyISAM, InnoDB and NDB. For other engines > it doesn't matter (CSV, MEMORY, MERGE, BLACKHOLE and FEDERATED) either > don't have a disk storage format or the format they use is test based > (CSV) or based on MyISAM (and therefore not an issue). > > The current exception for the current releases is Falcon which is, for > the moment, unsupported on non-x86 architectures (although partial > support is due for the 6.0.4 release and there re further improvements > for the release after that (particularly on SPARC and PowerPC). However, > AFAIK there is currently no migration support between platforms - you > have to dump and reload a Falcon database. > > In practice, we generally recommend a dump and reload for absolute > compatibility for any engine and major migration such as this... > > Since we are talking about the 6.x release series, that doesn't affect > us now, but I'm merely offering it up for information :) > > MC > > (also mc at mysql.com) > > -- > Martin 'MC' Brown, mc at mcslp.com > Everything MCslp: http://planet.mcslp.com > > > >
