我正在使用一个生产MySQL数据库，我想：
QUESTION 1:这可能吗？ 我知道（1）是可能的，因为这里有一些文档http://dev.mysql.com/doc/refman/5.0/en/replication.html 。 但是我不确定我能不能同时得到（1）和（2）。 我问，因为我需要编写访问数据库的代码，因为它是每个人使用的生产数据库，有时我不能使用数据库。 我想写testing程序，使用复制奴隶（非永久性写访问），当我确定一切正常，我将运行我的程序使用主数据库，所以这些变化是永久的。 我想我的写作出现在奴隶，所以我可以确保正确的事情写入。
QUESTION 2:是否可以轻松地复制数据库？ 数据库有一个真正巨大的表格。 我认为数据库是在4GB的数量级。 我只能在周末做复制，所以我不打扰每个人。 但是恐怕一个周末的时间不足以复制整个数据库。 那么，有没有办法一件件做？ 还是有一些超级快速的方式来复制数据库？
QUESTION 3:设置一切有多复杂？ 我想可能会由于缺乏经验而花费很长时间，但是假设我有一个DBA为我做这项工作，我给他/她造成了多less麻烦？
任何帮助将不胜感激！ 顺便说一句，我很新的MySQL和数据库一般所以要温柔:)
我们使用这样的情况来testing/备份/生产。
我们的情况是这样的：
为了方便最后一部分，首先我们locking本地从站（“FLUSH TABLES WITH READ LOCK;”），然后我们简单地使用linux LVM来创build本地从站副本的数据存储的快照（所以我们有一个一致的on-磁盘快照）。 然后，我们使用rsync从testing服务器上的dar目录上的本地从服务器快照中复制。 这有一个副作用，即保持新表未被推到生产环境中，因此正在进行的具有新function的项目不会被吹走。
这与MyISAM表正常工作，这是我们正在使用，我们没有切换到InnoDB。 恐怕我不确定rsync部分是否适用于InnoDB。如果你使用InnoDB，你可能会在testing服务器上使用mysqldump> dumpfile.sql和mysql <dumpfile.sql。
问题1：
在Linux上，您可以使用LVM可写快照创build副本的冻结图像，然后在不影响真实副本的情况下更改您的内容。
这可能是这样的：
在副本上：
stop true-replica mysql instance; create a writeable snapshot; start throwaway-replica mysql instance; restart true-replica and restart replication;
然后，你可以做任何你喜欢的一次性副本，然后，一旦你完成它，停止实例，并删除快照。
问题2：我不清楚你的意思。 通常情况下，MySQL复制会持续运行，使副本保持最新状态，对主服务器几乎没有影响。
问题3：MySQL很容易pipe理。 LVM可能需要一些习惯，并可能需要额外的磁盘空间。
Shlomo – 你的一些术语很混乱。 对于数据库，术语“复制”往往意味着保持数据库的远程副本最新的机制。 这需要复制主服务器来跟踪对数据的更改 – MySQL使用二进制日志进行更新，插入和删除操作。 复制从站需要获取这些logging的更改，然后将其应用于其自己的数据集。
初始化一个奴隶可能会很棘手。 您需要一个包含主数据库快照的转储（大多数数据库转储机制将提供给您）以及复制日志中将logging下一个更新/删除/插入的点 – 同样也包含许多数据库转储进程可以在转储中包含此复制点。 然后使用转储恢复您的复制副本，并将其configuration为从创build转储的复制点进行复制。
创build转储文件可能是干扰性的：对于MyISAM表，您需要停止MySQL服务器并将datadir的内容复制到dumpfile中，或者locking所有要包含在转储中的表，并从datadir中复制原始表文件或者mysqldump所需的表格，持续时间的locking。 在locking期间，locking表的更新将在转储过程中停顿 – 这可能是侵入性的。
对于Innodb，可以使用mysqldump生成转储，而不会对常规数据库用户产生太多的影响。 在内部，它将生成正在转储的数据的快照，使得即使在用户更新相同的表时，也可以将一致的数据集包含在转储中。 这将对性能产生影响，并且还需要维护快照的空间 – 关于在生成转储时由其他用户更改的行的等效大小。 显然，变化越多，磁盘空间就越大。 转储完成后，返回保存快照所用的空间。
一旦你的副本build立起来了，维持复制到从服务器的主机的影响就微乎其微了，通常只有百分之几。 所有真正的工作都是由从机更新数据集完成的，因为更改是通过复制日志来完成的。 使用内置的MySQL复制function，大多数用户能够保持复制整天运行，而不会对主数据库造成太大的影响。
如果您只希望从服务器进行更改，则只需在服务器开始和结束时启动和停止从服务器上的复制。 只要你的主人不是超级忙，奴隶通常会很快赶上现在的状态。
pipe理开销是在主服务器上维护复制日志。 磁盘上必须有足够的空间保存至less几天的日志，最好是几个星期的时间。 复制日志保存的时间越长，您的转储越长，可用于初始化副本。 如果与转储关联的复制日志已被清除，则无法使用转储来构build副本。 MySQL可以被configuration为在日志一旦超过一定的年龄阈值时删除日志，因此不需要日志轮换scipts。
正常模式是，一旦你有一个好的副本build成，你用它来转储 – 从而避免对主服务器的任何影响。 您从转储的副本应启用“日志 – 从属更新”，以便它反过来保持每个更改的复制日志直接（这是一个坏主意，因为那么您的副本将偏离主）以及通过复制stream进行的每个更改 – 默认情况下它不会添加到复制日志。
我build议你玩一些testing机器，并设置复制，看看会发生什么。 一旦你掌握了它，这是非常容易和快速的。 另外，请查看可用的复制筛选选项 – 如果您只想复制master数据库的一个子集，这可能很有用。 这些在MySQL手册中：
16.2.3。 服务器如何评估复制过滤规则