1 |
kashani wrote: |
2 |
|
3 |
> On 4/6/2011 3:47 PM, Alex Schuster wrote: |
4 |
> >> On Linux there is no difference between the on disk format so rsync |
5 |
> >> away assuming you're keeping roughly the same Mysql version. |
6 |
> > |
7 |
> > Um, but only when the architecture is identical. I'm pretty sure binary |
8 |
> > data is stored in different format on 32bit and 64bit systems. |
9 |
|
10 |
> I had done it myself in the past a number of times without issue, but |
11 |
> here's the documentation to back it up. |
12 |
> |
13 |
> kashani |
14 |
> |
15 |
> http://wikis.sun.com/display/WebStack/MySQL64bitARC |
16 |
> |
17 |
> "It should be noted that, when switching between 32bit and 64bit server |
18 |
> using the same data-files, all the current major storage engines |
19 |
> (with one exception) are architecture neutral, both in endian-ness and |
20 |
> bit size. You should be able to copy a 64-bit or 32-bit DB either way, |
21 |
> and even between platforms without problems for MyISAM, InnoDB and NDB. |
22 |
> For other engines it doesn't matter (CSV, MEMORY, MERGE, BLACKHOLE and |
23 |
> FEDERATED) either the engine doesn't have a disk storage format or |
24 |
> the format they use is text based (CSV) or based on MyISAM (MERGE; and |
25 |
> therefore not an issue). The only exception is Falcon, which is only |
26 |
> available in MySQL 6.0. |
27 |
> |
28 |
> It is generally recommended from MySQL that a dump and reload of |
29 |
> data for absolute compatibility for any engine and major migration." |
30 |
|
31 |
Interesting. I searched a little, and while there are many warnings that |
32 |
binary data will not survive when moved to another architecture, some people |
33 |
say this definitely is NOT a problem. I stand corrected. |
34 |
|
35 |
Wonko |