系统目录 › 数据库组件 › MYSQLR、MYSQLR64－适合复制的 MySQL 数据库组件

MYSQLR、MYSQLR64－适合复制的 MySQL 数据库组件

功能概述

MYSQLR64 是基于 MySQL 数据库引擎的数据库组件 (http://www.mysql.org)。 它提供一种简便方法将数据库添加到任何应用。 这些组件还可用于复杂的 MYSQL 复制方案。 这些组件基于 MYSQL5 (CentOS 5.5/MySQL 5)，并且还可处理数据库复制。

通过数据库复制，可以将数据从一个 MySQL 数据库服务器（称为主服务器）复制到一个或多个 MySQL 数据库服务器（称为从服务器）。 可以针对主服务器-从服务器复制、主服务器-主服务器复制以及涉及两个以上主服务器的复制设置 MYSQLR64 组件。

通过 Web 界面完成复制设置、管理和监控。 通过 Web 界面可以方便地开始复制，并且给主服务器造成的停机时间几乎为零。 出现问题时，还可以使用 Web 界面修复复制。 可以使用 Web 界面从早期数据库组件（例如 MYSQL 和 MYSQL5）复制数据库。 MYSQLR64 还提供了一种简便的方法用于管理和浏览您的数据库（基于 phpMyAdmin）。

在许多情况下，复制功能非常有用：

• 向外扩展解决方案－在多个节点之间分散负载以改善性能（“主服务器-主服务器”配置）。
• 故障切换解决方案－在主服务器-主服务器复制中使用多个节点，以便当某组件发生故障时，可以单独使用其他组件来为应用服务。 （MYSQLR64 不会自动处理故障；当某台 MYSQL 服务器发生故障时，您的应用应该使用 MYSQLR64 来检测故障并停止运行。 ）
• 备份解决方案－包括两个（或更多个）节点，一个作为主服务器运行，其他作为从服务器运行。 应用只使用主服务器；从服务器用于执行备份（在此情况下，可以停止数据库以实现备份一致性）或者单纯地用于执行繁重的数据（报告、摘要或未更改数据的任何操作）分析，实现这些目的并不需要加载主服务器，因此不影响应用的性能。 （MYSQLR64 不自动备份数据库，您需要自行管理备份。 ）

使用默认配置时，MYSQLR64 的功能与某个带有管理 Web 界面的 MYSQL5 组件完全相同。 要将 MYSQLR64 用于复制方案，至少需要提供两个使用适当配置的 MYSQLR64 组件（请参见典型用法）。

MYSQLR64 在应用定义的卷（可在每个 MYSQLR64 实例上配置）上存储数据库。 MYSQLR64 在空卷上启动时，将自动创建一个空数据库。

重要信息！ 使用复制时，不应混合使用 32 位和 64 位 MYSQLR 组件，因为数据库文件是按原样从主服务器复制到从服务器的。 此外，32 位版本的组件中的数据卷不应与 64 位版本的相同组件一起使用（反之亦然）。 要在 32 位和 64 位 MYSQLR 版本之间迁移数据库，请根据此处所述，在一台主机上转储数据库，然后在另一台主机上导入这些数据库。

边界

资源

终端

默认接口已启用。 它用于诊断和故障排除（通过 SSH）。 此组件的未来版本可能会禁用 SSH 访问。
重要信息！ rin 和 rout 终端用于 SSH (tcp 22) 和 MYSQL (tcp 3306) 数据。 在将网关/VPN 用于连接这些终端时，防火墙应配置为允许两个端口。

用户卷

数据卷可以选择在其顶级目录中包含一个 my.cnf 文件，该文件中包括 MYSQL 配置选项。 有关更多详细信息，请参阅自定义配置一节。 该功能在 MYSQLR64 1.6.1 或更高版本中可用。

重要信息！

• 数据卷必须专用于 MYSQL 实例（不能与其他组件共享）。
• 数据卷不应使用任何文件系统进行格式化，因为它将用于构建 LVM 卷。 如果您使用通过任何文件系统（可能包含来自旧 MYSQL 组件的文件）格式化的卷，该组件将无法启动，以防止删除数据库/文件。

要迁移旧组件（MYSQL、MYSQL5、MYSQL64）的数据库，从物理服务器的数据库或 MYSQLR（如果从 32 位迁移到组件的 64 位版本）的数据库迁移，有关其他组件的过程，请参阅“从其他组件迁移数据库”。

属性

自 MYSQLR64 1.6.8 起，已删除 use_old_passwords 属性。 如果需要启用 old_passwords，请按如下所述创建自定义配置。

如果指定了 error_log_filename 但未连接 log 终端或者无法挂接文件系统，MYSQLR 组件将无法启动。

高级属性

自定义配置

该功能在 MYSQLR64 1.6.1 或更高版本中可用。

MYSQLR64 允许使用自定义 MYSQL 配置文件，该文件可以提供其他配置选项或覆盖在 /etc/my.cnf 中指定的现有配置。

要使用自定义配置，请创建名为 my.cnf 的文件并将其放在数据卷的顶级目录中。 文件的格式应遵循 MYSQL 文档中所述的 MYSQL 选项文件语法。

例如：在使用 InnoDB 时可以使用以下内容调整 MYSQLR64 以提高性能 （为 MyISAM 优化了默认的 MYSQLR64 配置）。 该示例以使用 512M 内存（MYSQLR64 的默认设置）为基础。

[mysqld]
# Shrink down MyISAM buffers
key_buffer = 512K
myisam_sort_buffer_size = 512K

# Make InnoDB the default storage engine (optional)
default-storage-engine = INNODB

# Set InnoDB buffer size
innodb_buffer_pool_size=350M
innodb_log_file_size=128M
innodb_log_buffer_size=4M
innodb_thread_concurrency=8

# If you do not have too many tables use this option, so you will not have uncontrolled innodb main tablespace growth which you can’t reclaim.
innodb_file_per_table=1

重要信息！ 在复制模式下使用时，只要您修复/启动复制，MYSQLR64 就会同步数据卷中的 my.cnf 文件，因此从服务器将与主服务器具有相同配置。

Web 界面

MYSQLR64 提供了一个 Web 界面，通过 CA 3Tera AppLogic 编辑器中的“登录 (Web)”选项在其 ui 终端和默认界面中均可访问该界面。 使用 Web 界面需要 HTTP 身份验证。 将用户名保留为空并使用 web_pwd 的值作为密码。 该界面具有以下功能：

• 查看服务器状态
  • 启动/停止/重新启动 mysql 服务
  • mysql 服务器状态和运行时间
  • mysql 复制状态（仅用于此组件）
  • 最新的 mysql 日志条目
  • 组件运行时间
  • 组件内存使用情况
  • 组件磁盘使用情况
• 迁移内容（仅当存在 old_data 卷时可见）
  • 迁移内容－将 old_data 卷的内容复制到数据卷。 用于提供从 MYSQL 和 MYSQL5 组件的轻松升级。 将擦除数据卷上的所有数据。
• 查看/管理复制
  • mysql 复制状态（仅用于此组件）
  • 启动/修复复制。 在这种情况下，将擦除该组件中的数据库，并从主组件从头开始启动复制。 这不会影响主组件上的数据库（不删除主组件上的任何数据），也不会使主 MYSQLR64 组件产生任何停机时间。 在修复期间，组件将处于脱机状态，不应使用它。
  • 删除快照－删除在此组件上创建的数据库快照，以在其从组件上启动/修复复制。 在正常运行中，该组件中将不保留任何快照，如果显示“删除快照”按钮，则表明从组件当前正从此组件启动复制，或者以前的启动复制尝试失败。 有助于在删除快照之前确保没有从组件正在使用该快照。 如果组件中没有快照，此选项将不可见。
  • 重置主日志位置－在多节点主-主复制中添加新服务器时，在当前组件上运行复制启动/修复后，您需要登录到通过其“rout”终端连接到此组件的组件的 Web 界面并单击“重置主日志位置”。
• 管理数据库

使用 PhPMyAdmin 浏览并编辑数据库

复制设置和维护

将主-从复制添加到 MYSQLR64 组件

CA 3Tera AppLogic 使您可以在不丢失任何数据的情况下，将主-从复制添加到现有的 MYSQLR64 组件。

将主-从复制添加到 MYSQLR64 组件

1. 在现有组件上将 rpl_mode 设置为 master
2. 将新的 MYSQLR64 组件添加到具有空数据卷的应用。 将其 rout 终端连接到当前组件的 rin 终端。
3. （可选）如果您将要在主-主复制中使用它，请将当前组件上排除的终端连接到新组件的 rin 终端。
4. 重新启动应用。
5. 登录到新组件的 Web 界面，并从“管理复制”选项卡选择“启动/修复复制”。 日志记录所用的时间取决于主服务器上的数据大小。 如果您使用 INSSLR 来访问 MYSQLR64，请帮助确保将超时属性设置为较大的值 (36000) 来避免超时。 确认在客户端的任何代理（最好根本不使用代理）中都没有超时。

在启动复制后，登录到两个 MYSQLR64 组件上的 Web 界面并验证复制状态。 在 5 分钟或更短的时间内，复制应在两个组件上运行。

将 MYSQLR64 组件添加到主-从复制

CA 3Tera AppLogic 使您可以在不丢失任何数据的情况下，将新的 MYSQLR64 组件添加到现有的主-主复制。

将 MYSQLR64 组件添加到主-从复制

1. 将新的 MYSQLR64 组件添加到具有空数据卷的应用。 以 dbN 为例，假定您已经具有 N-1 个 MYSQLR64 组件 (3 <= N <= 10)，且每个组件的 rout 终端连接到循环设置中下一个组件的 rin 终端（db1 rout 连接到 db2 rin，依此类推）。
2. 将 dbN 的 rpl_mode 设置为 master_and_slave。
3. 将 dbN-1 组件的 rout 终端连接到 dbN 组件的 rin 终端。
4. 将 dbN 组件的 rout 终端连接到 db1 组件的 rin 终端。
5. 重新启动应用，以使更改生效。 在重新启动之后，复制直到过程结束时才会同步。 在执行该过程期间，写入一个组件的数据可能不会在所有其他组件上复制。
6. 登录到 dbN 组件的 Web 界面，并从“管理复制”选项卡选择“启动/修复复制”。 日志记录所用的时间取决于主服务器上的数据大小。 如果您使用 INSSLR 来访问 MYSQLR64，请帮助确保超时属性设置为较大的值 (36000) 来避免超时。 此外，帮助确保在客户端的任何代理（最好根本不使用代理）中都没有超时。
7. 在启动复制后，登录到 dbN-1 的 Web 界面，并选择“重置主日志位置”。 日志记录使应用读取 dbN-1，并从开头读取 dbN 的二进制日志。

登录到所有 MYSQLR64 组件的 Web 界面并验证复制状态，在 5 分钟或更短的时间内复制应在所有组件上运行。

在主-从配置中修复复制

CA 3Tera AppLogic 使您可以在不丢失任何数据的情况下，在主-从设置中修复复制。

在主-从配置中修复复制

1. 登录到从组件的 Web 界面，然后选择“启动/修复复制”。 日志记录所用的时间取决于主服务器上的数据大小。 在操作过程中，从组件上的 mysql 服务会停止。 主组件上未产生停机时间。 此操作相当于将新组件添加到现有的 MYSQLR64 组件。 如果您使用 INSSLR 来访问 MYSQLR64，请验证超时属性是否设置为较大的值 (36000) 来避免超时。 此外，请确认客户端的任何代理（最好根本不使用代理）中都没有超时。

在启动复制后，登录到从 MYSQLR64 组件的 Web 界面，然后验证复制状态，复制应在 5 分钟或更短的时间内运行。

在主-主配置中修复复制

CA 3Tera AppLogic 使您可以在不丢失任何数据的情况下，在主-主设置中修复复制。

登录到报告复制失败的组件的 Web 界面，然后选择“启动/修复复制”。 日志记录所用的时间取决于主服务器上的数据库大小。 在操作过程中，组件上的 mysql 服务会停止。 主组件上未产生停机时间。 直到修复结束，数据库才会在所有主组件之间同步。 在修复期间，可能无法在其他所有 MYSQLR64 组件上复制数据库更新。

此组件上的所有数据将从主组件初始化。 如果当前组件上的数据库有任何更新，由于复制中断，因此这些更新将丢失。 在此类情况下，请手工解决冲突。

在主-主配置中修复复制

1. 登录到已将其 rout 终端连接到运行修复复制的组件的组件的 Web 界面。 选择“重置主日志位置”。 设置主日志可使应用从开头读取固定组件的二进制日志。 如果您使用 INSSLR 来访问 MYSQLR64，请验证超时属性是否设置为较大的值 (36000) 来避免超时。 此外，请确认客户端的任何代理（最好根本不使用代理）中都没有超时。

登录到所有 MYSQLR64 组件的 Web 界面，然后查看复制状态。 在 5 分钟或更短的时间内，复制应在所有组件上运行。

复制监控

有一个 cron 作业可监控 MYSQLR64 组件之间的复制。 如果启用了复制，cron 作业将每两分钟运行一次，并在以下情况下向网格显示板发送警报：

• 复制未运行（网格显示板显示以下内容：主服务器复制未运行，请检查!）
• 复制正在运行，但落后于主服务器的时间太长（网格显示板显示以下内容：复制落后于主服务器的时间太长，请检查!）
• 数据卷上的磁盘空间不足（可用空间 < 20%）。 无论是否已启用复制，都请检查此项内容（网格显示板显示以下内容：数据卷上的可用空间不足，请检查!）
• binlogs 卷上的磁盘空间不足（可用空间 < 20%）。 无论是否已启用复制，都请检查此项内容（网格显示板显示以下内容：binlogs 卷上的可用空间不足，请检查!）

在此类情况下，用户应手工解决该问题。

在复制失败的情况下，可以按照上节所述使用 Web 界面进行修复。

复制监控

有一个 cron 作业可监控 MYSQLR64 组件之间的复制。 如果启用了复制，cron 作业将每两分钟运行一次，并在以下情况下向网格显示板发送警报：

• 复制未运行（网格显示板显示以下内容：主服务器复制未运行，请检查!）
• 复制正在运行，但落后于主服务器的时间太长（网格显示板显示以下内容：复制落后于主服务器的时间太长，请检查!）
• 数据卷上的磁盘空间不足（可用空间 < 20%）。 无论是否已启用复制，都请检查此项内容（网格显示板显示以下内容：数据卷上的可用空间不足，请检查!）
• binlogs 卷上的磁盘空间不足（可用空间 < 20%）。 无论是否已启用复制，都请检查此项内容（网格显示板显示以下内容：binlogs 卷上的可用空间不足，请检查!）

在此类情况下，用户应手工解决该问题。

在复制失败的情况下，可以按照上节所述使用 Web 界面进行修复。

自定义计数器

MYSQLR64 组件通过 mon 终端报告以下自定义计数器。

以下计数器属于 MySql 计数器组：

错误消息

当组件无法启动时，网格控制器的组件日志文件或系统日志中可能会出现下列消息：

此外，在组件运行时，网格显示板上可能会显示以下错误：

典型用法

简单的双层应用（无复制）

下图显示 MYSQLR64 组件在双层 Web 应用中的典型用法：

正在使用的组件：

• user－输入网关
• web－Web 服务器
• db－MYSQLR64 数据库组件
• logs－用于存储日志文件的 NAS 组件
• content－用于存储 Web 服务器内容的 NAS 组件
• admin－用于查看日志文件的输入网关
• mon一MON 组件

客户端请求到达用户网关。 网关会将请求转发到 Web 服务器，后者处理请求。 当 Web 上的脚本（例如：Perl 或 PHP）需要访问永久数据时，它们会通过 Web 服务器的 out 终端使用 db 组件。 db 组件配置为在由 logs 公开的共享的根目录内存储其日志文件。

使用浏览器，管理员可连接到 admin 网关来查看 mysql 或 Web 服务器日志文件。 admin 网关将请求转发给日志 NAS 组件。

示例属性配置（未列出的属性应保留为默认值）：

注意：还必须在 db 组件以及 logs、content 和 mon 组件上配置数据卷。 要创建可在此处使用的应用卷，请参阅《网格用户指南》。

可扩展的双层应用（无复制）

下图显示 MYSQLR64 组件在双层 Web 应用中的典型用法，其中数据库用于在负载均衡的多个 Web 服务器之间共享状态和数据。 此外，此示例有一个单独的用于维护的输入，管理员通过该输入可以登录并访问用于维护的数据库；此示例还有一个可供管理员登录并查看 mysql 错误日志的输入。

正在使用的组件：

• user一用户请求的输入网关
• web_lb一用户请求的 Web 负载均衡器
• web1、web2一有活动内容的 Web 服务器（例如：CGI 脚本）
• db－数据库
• logs－用于存储和访问数据库和 Web 服务器错误日志文件
• content－用于存储 Web 服务器内容
• maint－用于维护访问的输入网关
• admin－管理员使用的通用 Linux5 服务器
• gway－供管理员访问 Internet 的网络网关
• mon一MON 组件

客户端请求到达用户网关。 该网关将请求转发给 web_lb 负载均衡器，后者将请求定向到 Web 服务器 web1 和 web2 中的一个。 Web 服务器访问 db 数据库。

db 数据库以及 web1 和 web2 服务器通过 log 终端将其日志文件写入 logs 组件。 此外，管理员还可以通过 maint 网关登录到 logs 组件并查看日志文件。

此外，管理员还可以通过 admin 服务器的 maint 网关在 SSH 上登录（需要设置公钥-私钥）。 从 admin 服务器中，管理员可以访问 db 数据库中的统计信息或更改数据库架构。 例如：admin 服务器可以通过 gway 网关访问 Internet，以下载库或数据库架构的较新版本。

示例属性配置（未列出的属性应保留为默认值）：

注意：

• 还必须在 db、logs、content 和 mon 组件上配置数据卷。

maint、admin、gway、mon 以及 log 组件不是运行双层应用所必需的。 如果存在，admin 服务器可能具有用于数据库清理、发送电子邮件等的 cron 作业。

具有主-从复制的 N 层应用（适合于备份）

下图显示 MYSQL 组件在将数据库复制到从服务器的 Web 应用中的典型用法。 从服务器可用于创建数据的一致备份，而不停止主服务器，因此引起的应用停机时间为零。

正在使用的组件：

• user一用户请求的输入网关
• admin－用于对 MYSQLR64 组件进行日志文件访问和网站访问的输入网关
• sw－将 HTTP 流量拆分到每个 MYSQLR64 组件
• web_lb一用户请求的 Web 负载均衡器
• web1、web2一有活动内容的 Web 服务器（例如：CGI 脚本）
• master－配置为主组件的 MYSQLR64
• slave－配置为从组件的 MYSQLR64
• content－用于存储 Web 服务器内容
• logs－用于存储数据库和 Web 服务器日志文件
• mon一MON 组件

客户端请求到达用户网关。 该网关将请求转发给 web_lb 负载均衡器，后者将请求定向到 Web 服务器 web1 和 web2 中的一个。 Web 服务器访问主数据库。

从组件连接到主组件并复制其数据。 为了执行 SQL 数据或大型分析的一致备份，可以随时停止从组件，而不会影响主组件和其余应用的性能。

通过端口 8080 和 8081 上的 admin 网关可以对主组件和从组件进行 Web 访问。

master、slave、web1 和 web2 组件配置为在由 logs 公开的共享的根目录内存储其日志文件。 此外，管理员还可以通过 admin 网关查看日志文件。

示例属性配置（未列出的属性应保留为默认值）：

主组件

从组件

注意：

• 必须在 logs、content 和 mon 组件上配置数据卷。
• 数据卷和 binlogs 卷必须在主服务器和从服务器上都进行配置。 它们应有足够空间来处理数据和日志。
• 每个组件都应使用自己的卷（卷不能在组件间共享）。

admin、mon 以及 log 组件不是复制操作所必需的。

具有主-主复制的 N 层应用（适合于负载均衡）

下图显示 MYSQLR64 组件在 Web 应用中的典型用法，其中在主-主复制方案中将数据库复制到两个服务器。 在此用例中，应用在负载均衡操作期间使用 WEB 和 MYSQLR64 服务器。 此外，在其中一个 WEB/MYSQLR64 实例失败的情况下，其他 WEB/MYSQLR64 实例可用于防止应用停机。

正在使用的组件：

• user一用户请求的输入网关
• admin一用于日志文件访问的输入网关
• sw－将 HTTP 流量拆分到每个 MYSQLR64 组件
• web_lb一用户请求的 Web 负载均衡器
• web1、web2一有活动内容的 Web 服务器（例如：CGI 脚本）
• db1 和 db2－同时将 MYSQLR64 组件配置为主组件和从组件
• content－用于存储 Web 服务器内容
• logs－用于存储数据库和 Web 服务器日志文件
• mon一MON 组件

客户端请求到达用户网关。 该网关将请求转发给 web_lb 负载均衡器，后者将请求定向到 Web 服务器 web1 和 web2 中的一个。 web1 使用 db1 数据库组件，web2 使用 db2 数据库组件。 连接 db1 和 db2，以复制 Web 服务器对数据库进行的更新。 每个 MYSQLR64 组件都将偏移（与其 server_id 相等）用于其 auto_increment 列，以防出现重复条目。

通过端口 8080 和 8081 上的 admin 网关，可以对 db1 和 db2 进行 Web 访问。

db1、db2、web1 和 web2 组件配置为在由 logs 公开的共享的根目录内存储其日志文件。 此外，管理员还可以通过 admin 网关查看日志文件。

示例属性配置（未列出的属性应保留为默认值）：

db1

db2

注意：

• 必须在 logs、content 和 mon 组件上配置数据卷。
• 数据卷和 binlogs 卷必须在 db1 和 db2 上都进行配置。 每个组件都应使用自己的卷（卷不能在组件间共享）。
• 执行主-主复制时，需要从空数据卷开始。

admin、mon 以及 log 组件不是复制操作所必需的。

具有多节点主-主复制的 N 层应用（适合于负载均衡）

下图显示 MYSQLR64 组件在 Web 应用中的典型用法，其中在主-主复制方案中将数据库复制到四个服务器。 在此用例中，应用在负载均衡操作期间会使用所有的 WEB 和 MYSQLR64 服务器。 此外，在其中一个 WEB/MYSQLR64 实例失败的情况下，其他 WEB/MYSQLR64 实例可用于防止应用停机（MYSQLR64 不处理故障）。

正在使用的组件：

• user一用户请求的输入网关
• admin一用于日志文件访问的输入网关
• sw－将 HTTP 流量拆分到每个 MYSQLR64 组件
• web_lb一用户请求的 Web 负载均衡器
• web1、web2、web3、web4－包含活动内容的 Web 服务器（例如：CGI 脚本）
• db1、db2、db3、db4－同时将 MYSQLR64 配置为主组件和从组件
• content一数据库错误日志文件、Web 内容和 Web 日志的存储
• logs－用于存储数据库和 Web 服务器日志文件
• mon一MON 组件

客户端请求到达用户网关。 网关会将请求转发到 web_lb 负载均衡器，后者将请求定向到 Web 服务器（web1、web2、web3 和 web4）中的一个。 每个 Web 服务器都使用自己的数据库组件。 所有数据库组件都以循环方式连接，以复制 Web 服务器对数据库进行的更新。 例如：将对 db1 的更新复制到 db2、db3 和 db4。 每个 MYSQLR64 组件都将偏移（与其 server_id 相等）用于其 auto_increment 列，以防出现重复条目。

通过端口 8080、8081、8082 和 8083 上的 admin 网关，可以对 db1、db2、db3、db4 进行 Web 访问。

db1、db2、web1 和 web2 组件配置为在由 logs 公开的共享的根目录内存储其日志文件。 此外，管理员还可以通过 admin 网关查看日志文件。

示例属性配置（未列出的属性应保留为默认值）：

db1

db2

db3 组件

db4

注意：

• 必须在 logs、content 和 mon 组件上配置数据卷。
• 数据卷和 binlogs 卷还必须在所有 db 组件上都进行配置。 每个组件都应使用自己的卷（卷不能在组件间共享）。
• 执行多主复制时，需要从空数据卷开始。

admin、mon 以及 log 组件不是复制操作所必需的。

在不同工具上运行的 N 层应用（适合于负载均衡和故障切换）

下图显示 MYSQLR64 组件在运行于多个工具中的 Web 应用中的典型用法。 使用此设置时，可以有两个或多个相同的应用在不同工具中运行，同时将数据库复制到主-主设置中的所有应用。 这在以下两种情况下很有用：

• 地理负载均衡－设置 2 个（或更多）此类应用，以使用户可以使用与其地理区域最接近的应用来获得更理想的响应时间（使用 DNS 实现负载均衡）
• 故障切换－设置 2 个（或更多）此类应用，这样如果正在运行一个应用的整个工具关闭（或应用本身关闭），可以使用其他应用来防止停机时间。

主应用

从应用

正在使用的组件：

• user一用户请求的输入网关
• admin一用于日志文件访问的输入网关
• sw－将端口 8080 从 admin 重定向到主应用或从应用上的 ui
• vpn－要连接到 master=/=slave 组件以复制数据库的远程应用的输入
• web_lb一用户请求的 Web 负载均衡器
• web1、web2一有活动内容的 Web 服务器（例如：CGI 脚本）
• master－将 MYSQLR64 配置为主组件
• slave－将 MYSQLR64 配置为从组件
• content一数据库错误日志文件、Web 内容和 Web 日志的存储
• logs一数据库错误日志文件的存储

客户端请求到达用户网关。 该网关将请求转发给 web_lb 负载均衡器，后者将请求定向到 Web 服务器 web1 和 web2 中的一个。 Web 服务器访问主数据库。 主组件连接到远程（从）应用以复制数据库，仅有的差别是从服务器的 server_id 以及网络设置。 远程应用通过 vpn 网关连接到主组件，该网关配置为仅允许来自远程应用的 vpn 网关的连接。 两个应用中的主组件和从组件在主-主设置中运行，这样它们始终具有相同的数据。

示例属性配置（未列出的属性应保留为默认值）：

通过端口 8080 上的 admin 网关可以对主组件和从组件进行 Web 访问。

主组件

主 vpn

从组件

从 vpn

远程应用是精确副本，仅有的差别是 user、admin 和 vpn 组件的网络设置、vpn 组件与 master=/=slave 之间的连接以及 master=/=slave 组件的 server_id（它应该是唯一的）。

从其他组件迁移数据库

如果需要从 MYSQLR 迁移到 MYSQLR64（或执行相反的迁移），不能只在 64 位组件上使用 32 位组件中的卷（反之亦然），因为这可能会导致数据损坏。 实现此目的的建议方法是是在旧组件上转储数据库，将转储的文件传输到新组件，然后将数据库导入新组件。 下面是执行此操作的过程：

• （可选）阻止访问旧数据库－这是可选操作，其目的只是确保数据库转储时不被修改。 实现此目的的一种方法是当组件输入终端上未连接任何对象时启动该组件。
• 在旧组件上转储所有数据库。 执行此操作之前，请确认数据卷上有足够的空间（如果没有足够的空间，您始终可以调整数据卷的大小）。 要实现此目的，可以启动组件，登录该组件并执行以下命令：
  • mysqldump --all-databases --lock-all-tables | gzip > /mnt/data/my_dump.sql.gz
• 停止应用。
• 创建新应用卷，该卷将存储新组件 (ext3-snapshot) 的数据库。 确认该卷的大小足以保存数据库转储文件 (/mnt/data/my_dump.sql.gz) 和数据库本身。
• 将数据库转储文件传输到新建的卷（以下是使用两个带有外部 Internet 访问的 Filer 设置复制数据库的唯一方式；如果这不适合您的配置，也可以从网格到外部服务器使用 scp 来复制数据库，然后回到目标卷）：
  • 使用卷管理命令和两个 Filer（每个卷一个）分别管理每个卷。 确保在 vol manage 命令行上传递外部 IP 信息，这样每个 Filer 都可以彼此访问以便复制两个卷之间的数据库。 要获得有关如何指定外部网络设置的更多信息，请参见 vol manage 帮助。
  • 在源卷的 Filer 中，执行以下命令：cat /etc/ssh/ssh_host_rsa_key.pub >> /root/.ssh/authorized_keys
  • 在目标卷的 Filer 中，执行以下命令：scp -pr -i /etc/ssh/ssh_host_rsa_key IP_address_to_source_filer:/mnt/vol/my_dump.sql.gz /mnt/vol/。
  • 在复制数据库以后，您可从两个 Filer 中退出。
• 编辑应用并添加 MYSQLR/MYSQLR64 的新实例，将其参数化，连接它并将新建的卷分配给新的实例。 此时，可从应用删除旧的 MYSQLR/MYSQLR64 实例（然而为了备份目的您可能需要暂时保留它，直到您可以确认数据库被正确地转移到新的实例）。
• 导入数据库－启动新的组件，登录到其中并执行以下命令：
  • zcat /mnt/data/my_dump.sql.gz | mysql

数据库现已传输，组件已准备就绪。

说明

请注意下列各项：

• 为在默认情况下使用的 MyISAM 存储引擎优化 MYSQLR64 性能。 如果要为 Innodb 增强性能，或者只是想要为您的应用微调 MYSQL 服务，请参见自定义配置部分，以了解有关如何将配置参数添加到现有配置的详细信息。 该功能在 MYSQLR64 1.6.1 或更高版本中可用。
• MYSQLR64 仅使用异步复制（MySQL 不支持同步复制）。
• MYSQLR64 可在 2 分钟内检测到复制错误，并通过在网格显示板上发布消息来通知用户。 然后，用户可使用 MYSQLR64 GUI 来修复问题（MYSQLR64 不提供自动恢复）。
• 启动 MYSQLR64 后，将在组件日志文件中写入一条消息，指出 chmod 无法修改 mysql 日志文件的所有者。 此问题是意料之中的，不会影响 MYSQLR64 组件的操作。
• 单个复制中 MYSQLR64 组件的理论最高数量是 10。 当以循环方式复制数据时，增加 MYSQLR64 组件的数量会增加从服务器更新其数据库的时间。 复制中的组件实际最大数量可能更低，这取决于您的应用、负载和需求（从服务器的即时更新在诸如数据备份的方案中可能并不重要）。

重要信息！ 为数据库创建用户时，请确认所创建的用户对他们连接时所在的主机没有任何限制。 例如：

mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;

• 卷要求
  • 数据卷大小应该是 100 MB 或更大—当前已启用 InnoDB 引擎，它在数据卷上占用大约 22 MB 的空间。 在该版本中，没有办法将它禁用，即使您没有将 InnoDB 用作数据存储。
  • 数据卷不应使用任何文件系统进行格式化，因为它将用于构建 LVM 卷（该卷应该是未格式化的）。 如果使用任何文件系统格式化了某个卷（可能包含旧 MYSQL 组件中的文件），组件将无法启动，并阻止您删除文件。
  • 在分配的数据卷空间中，有 20% 用于启动/修复复制，这样，就留下了 80% 的卷空间用于数据库存储。
  • 在复制方案中使用 MYSQLR64 时，无论作为主服务器、从服务器还是 master_and_slave，您都必须提供 binlogs 卷。 二进制日志按 100 MB 的大小进行轮转，轮转后保留 2 天，此后将被删除。 如果组件也作为从服务器运行，中继日志也会被存储到 binlogs 卷。您将需要至少 500 MB binlogs 空间来运行主服务器-主服务器复制。 实际大小取决于所执行的 MySQL 更新/插入查询的强度，要正常运行应用，需要数 GB 的 binlogs 卷。
• 连接到 MYSQLR64 的组件负责创建自己的数据库和表（如果不存在）。 或者，您可以在数据卷上手工复制初始数据库。
• 连接到 MYSQLR64 的 in 终端的组件或服务器应该装有 MySQL 客户端库，这样才能访问 MySQL 服务器和提交请求。 组件目录中提供的所有虚拟服务器（包括通用 LINUX 服务器）都装有 MySQL 客户端库。
• 参考资料：
  • http://www.mysql.com－MySQL 网站

http://dev.mysql.com/doc/refman/5.0/en/index.html－MySQL 5.0 文档

组件中使用的第三方开源软件

MYSQLR64 除了使用其基类 LUX64 所用的第三方开源软件包之外，还使用下列第三方/开源软件包。

MYSQLR 故障排除

MYSQLR 组件在重新启动时冻结

从 MYSQLR 1.6.2 开始，您可以设置/更改根数据库帐户的密码。 但是，MSYQLR 组件有几个主机名不同的根帐户。 在设置/更改密码时，应始终使用 root@% 帐户。 root@% 帐户是连接到 MYSQLR in 终端的组件的帐户，将针对该帐户进行身份验证。 其他根帐户仅由本地用户使用，并且决不可为这些根帐户设置密码，因为这样做将导致 MYSQLR 组件无法启动。

注意：如果没有为 root@localhost 帐户设置密码，则这不是安全问题，因为此帐户只能由组件上的本地用户使用，并且有权访问组件的任何人都可以更改密码。

恢复在更改根数据库密码之后无法启动的 MYSQLR 组件

要恢复因更改数据库根密码而无法启动的组件，请执行以下步骤：

1. 在调试模式下启动组件或应用。

   组件启动命令

   comp start main.MYSQLR --debug 
   

   应用启动命令

   app start --debug 
   

   在启动组件几秒钟之后，您应该能够登录到该组件。 不必等待组件超时。

2. 通过 SSH 登录到组件并执行以下命令：

   mysql -p -e "update mysql.user set Password='' where User='root'" 
   mysqladmin -p flush-privileges 
   mysql -e 'update mysql.user set password=PASSWORD("NEWPASSWORD") where User="root" and Host="%"' 
   mysqladmin flush-privileges
   

重新启动组件以验证它是否已启动，以及用户 root 的“in”终端上的 mysql 连接是否需要密码。