H*******d
发帖数: 2394 | 1 问各位大牛一下哈：
公司的后台是建立在VM（Linux）上的，因为需要现在要把几个数据库（MySQL)合并成
两个。
合并后会只有两个数据库（webDB和nodeDB），一个是web访问的数据库（访问量没法预
测），一个是固定的节点访问的数据库（访问量根据节点的数量是计划过可计算的）。
web端的appserver会同时访问到这两个数据库，而节点的appserver只会访问节点的数
据库
现在的的问题是怎么部署这两个数据库：
1.用两个不同的VM来host不同的数据库
优点：两台VM基本独立，即使一台挂了，另一个VM还可以正常运转。
缺点：资源没法根据负载实时调配，每台VM的资源基本固定。
2.合并两个VM的资源成为一个更强的VM，运行两个mysql的实例
优点：系统可以自动动态调整资源。
缺点：VM挂掉了或者MySQL engine挂了就都挺了。
还有的问题是如果一个VM运行两个数据库，端口号是不是要不一样？
如果建立connection pool的话，是针对单个的实例还是可以两个一起？
平时主要是写代码，对与数据库弄得不是特别多，谢谢了 |
g***l
发帖数: 18555 | 2 太高深了，你需要SOLUTION ARCHITECT，偶们只看数据库SERVER |
a9
发帖数: 21638 | 3 正经点。
【在 g***l 的大作中提到】
: 太高深了，你需要SOLUTION ARCHITECT，偶们只看数据库SERVER
|
c*****d
发帖数: 6045 | 4 这两个数据库只查询不更新吗？
否则怎么同步？
【在 H*******d 的大作中提到】
: 问各位大牛一下哈：
: 公司的后台是建立在VM（Linux）上的，因为需要现在要把几个数据库（MySQL)合并成
: 两个。
: 合并后会只有两个数据库（webDB和nodeDB），一个是web访问的数据库（访问量没法预
: 测），一个是固定的节点访问的数据库（访问量根据节点的数量是计划过可计算的）。
: web端的appserver会同时访问到这两个数据库，而节点的appserver只会访问节点的数
: 据库
: 现在的的问题是怎么部署这两个数据库：
: 1.用两个不同的VM来host不同的数据库
: 优点：两台VM基本独立，即使一台挂了，另一个VM还可以正常运转。
|
g***l
发帖数: 18555 | 5 我确实不懂的么。既然是商业的，就该多咨询咨询，选个好的SOLUTION，不能穷糊弄。
【在 a9 的大作中提到】
: 正经点。
|
H*******d
发帖数: 2394 | 6 这两个数据库的数据面向的应用基本不一样，但是由于某些主table会有很多join，所
以某些主table会在两个数据库里面同时都有，而且这些主table更新很少。基本用
appserver上的app可以搞定同步。
【在 c*****d 的大作中提到】
: 这两个数据库只查询不更新吗？
: 否则怎么同步？
|
g***l
发帖数: 18555 | 7 最好还是CENTRALIZE，把DATA MODLE弄清楚弄干净，别弄两个SCHEMA将来不好管理，只
读的弄一个DATABASE里，TRANSACTION弄一个DATABASE里，这样将来BACKUP比较容易做
。既然怕当机，就别MYSQL了，能做CLUSTER么，能做MIRRORING么，做生意肯定要投资
的，不赚钱的话只能糊弄一下，勉强用，档就档了，买卖提不也经常档么。 |
H*******d
发帖数: 2394 | 8 主要是两个数据库面向的应用不同，没法合并。
不过还是谢谢了
【在 g***l 的大作中提到】
: 最好还是CENTRALIZE，把DATA MODLE弄清楚弄干净，别弄两个SCHEMA将来不好管理，只
: 读的弄一个DATABASE里，TRANSACTION弄一个DATABASE里，这样将来BACKUP比较容易做
: 。既然怕当机，就别MYSQL了，能做CLUSTER么，能做MIRRORING么，做生意肯定要投资
: 的，不赚钱的话只能糊弄一下，勉强用，档就档了，买卖提不也经常档么。
|
g***l
发帖数: 18555 | 9 什么面向的应用不同,这都是国内翻译的驴唇不对马嘴的,自己都不懂，所以翻译的都没
谱。应该是数据库支持不同的应用程序吧,如果能修改程序的话最好是把DATABASES合并
，合并的越晚，将来的麻烦就越大，将来还是不要搞DATA WAREHOUSE，把数据合并了搞
分析，所以一开始最好是弄好了。当然好多公司做不到，几个应用程序到时候会打架，
出现DEADLOCK, SLOW PERFORMANCE的时候又相互指责。如果没法合并，就最好分开两个
SERVER，谁也不管谁的事。
【在 H*******d 的大作中提到】
: 主要是两个数据库面向的应用不同，没法合并。
: 不过还是谢谢了
|
y****w
发帖数: 3747 | 10 你们可以考虑把两个库弄成一样，中间配置replication．现有的好处不会失去，还多
了ＨＡ和灵活性．
【在 H*******d 的大作中提到】
: 主要是两个数据库面向的应用不同，没法合并。
: 不过还是谢谢了
|
|
|
g***l
发帖数: 18555 | 11 千万别那么弄，两套SCHEMA，在弄个2-WAY REPLICATION，烦死了，REPLICATION OVER
HEAD很大，CONFLICT很多，DBA会烦死的，跟做小工的似的去RESOLVE CONFLICT。
【在 y****w 的大作中提到】
: 你们可以考虑把两个库弄成一样，中间配置replication．现有的好处不会失去，还多
: 了ＨＡ和灵活性．
|
H*******d
发帖数: 2394 | 12 对，支持的应用程序不同。
这样说吧。DB1上的应用程序基本上是web端的（public access），流量相对而言是没
法预计的。
DB2上的应用程序主要是连接公司自己建立的节点（比方说1000个node），这些节点都
是按计划定时查DB2，流量是可以计算的（平均每个节点一分钟查一次DB2）
但是对于这些节点本身的信息DB1和DB2所支持的应用程序都需要，所以把描述这些节点
的相关table在DB1和DB2中都建立了。主要是避免夸数据库join。当然如果要修改这些
节点的信息，应用程序会同时去两个DB修改。
当然这个设计不是最好的，是有历史原因的，现在也不好完全推翻从头做，所以只能在
现有基础上做优化。
【在 g***l 的大作中提到】
: 什么面向的应用不同,这都是国内翻译的驴唇不对马嘴的,自己都不懂，所以翻译的都没
: 谱。应该是数据库支持不同的应用程序吧,如果能修改程序的话最好是把DATABASES合并
: ，合并的越晚，将来的麻烦就越大，将来还是不要搞DATA WAREHOUSE，把数据合并了搞
: 分析，所以一开始最好是弄好了。当然好多公司做不到，几个应用程序到时候会打架，
: 出现DEADLOCK, SLOW PERFORMANCE的时候又相互指责。如果没法合并，就最好分开两个
: SERVER，谁也不管谁的事。
|
a9
发帖数: 21638 | 13 等于db2是只读的？
都没
合并
了搞
架，
两个
【在 H*******d 的大作中提到】
: 对，支持的应用程序不同。
: 这样说吧。DB1上的应用程序基本上是web端的（public access），流量相对而言是没
: 法预计的。
: DB2上的应用程序主要是连接公司自己建立的节点（比方说1000个node），这些节点都
: 是按计划定时查DB2，流量是可以计算的（平均每个节点一分钟查一次DB2）
: 但是对于这些节点本身的信息DB1和DB2所支持的应用程序都需要，所以把描述这些节点
: 的相关table在DB1和DB2中都建立了。主要是避免夸数据库join。当然如果要修改这些
: 节点的信息，应用程序会同时去两个DB修改。
: 当然这个设计不是最好的，是有历史原因的，现在也不好完全推翻从头做，所以只能在
: 现有基础上做优化。
|
H*******d
发帖数: 2394 | 14 web端的程序会同时在DB1和DB2上写东西，但所有的节点只会去读DB2的数据。唯一例外
的是所有的节点读DB2的时候会在把每一条读过的记录标记为已读（update），同时还
会更新节点描述的时间戳。
【在 a9 的大作中提到】
: 等于db2是只读的？
:
: 都没
: 合并
: 了搞
: 架，
: 两个
|
g***l
发帖数: 18555 | 15 这个好像只有2-WAY TRANSACTIONAL REPLICATION可以解决，俺说的是SQL SERVER,不是
没SUPPORT的MYSQL，同时改难免出现DEADLOCK和CONFLICT的，DBA会很烦。
【在 H*******d 的大作中提到】
: 对，支持的应用程序不同。
: 这样说吧。DB1上的应用程序基本上是web端的（public access），流量相对而言是没
: 法预计的。
: DB2上的应用程序主要是连接公司自己建立的节点（比方说1000个node），这些节点都
: 是按计划定时查DB2，流量是可以计算的（平均每个节点一分钟查一次DB2）
: 但是对于这些节点本身的信息DB1和DB2所支持的应用程序都需要，所以把描述这些节点
: 的相关table在DB1和DB2中都建立了。主要是避免夸数据库join。当然如果要修改这些
: 节点的信息，应用程序会同时去两个DB修改。
: 当然这个设计不是最好的，是有历史原因的，现在也不好完全推翻从头做，所以只能在
: 现有基础上做优化。
|
H*******d
发帖数: 2394 | 16 再问问哈。
是两台虚拟机上分别跑独立的DB呢，还是集中资源合成一个更强VM安装两个DB一起跑呢？
公司里一个同事的一件事两个DB放一个VM上，资源的利用更灵活，利用率也更高。
我们的server host partner（公司的server host在别的公司）想要把VM独立开来。
谢谢了
【在 g***l 的大作中提到】
: 这个好像只有2-WAY TRANSACTIONAL REPLICATION可以解决，俺说的是SQL SERVER,不是
: 没SUPPORT的MYSQL，同时改难免出现DEADLOCK和CONFLICT的，DBA会很烦。
|
y****w
发帖数: 3747 | 17 这两个db松耦合。 只考虑资源，还是用两个vm好了。 系统小，一共也没多少，无所谓
。系统大，多一个vm的开销也没啥。一个vm里面资源灵活分配？vm外面就把这事儿干了
，要不干嘛用vm？
呢？
【在 H*******d 的大作中提到】
: 再问问哈。
: 是两台虚拟机上分别跑独立的DB呢，还是集中资源合成一个更强VM安装两个DB一起跑呢？
: 公司里一个同事的一件事两个DB放一个VM上，资源的利用更灵活，利用率也更高。
: 我们的server host partner（公司的server host在别的公司）想要把VM独立开来。
: 谢谢了
|
H*******d
发帖数: 2394 | 18 资源的使用还是有很大的灵活性的。
比如现在总共有8个core和20GB的RAM可以用，如果放一个VM上，当某个DB闲的时候，这
些资源就都使用在忙的的DB上了。换句话说VM的OS本身就可以根据DB的负载来分配资源。
两个VM实际上就强制限制了每个DB的可用资源，虽然可以通过改变VM的参数再调整，但
不是OS实时自动调整。
【在 y****w 的大作中提到】
: 这两个db松耦合。 只考虑资源，还是用两个vm好了。 系统小，一共也没多少，无所谓
: 。系统大，多一个vm的开销也没啥。一个vm里面资源灵活分配？vm外面就把这事儿干了
: ，要不干嘛用vm？
:
: 呢？
|
y****w
发帖数: 3747 | 19 Resource of vm can be dynamicly tuned. Talk with your vm provider for
options.
源。
【在 H*******d 的大作中提到】
: 资源的使用还是有很大的灵活性的。
: 比如现在总共有8个core和20GB的RAM可以用，如果放一个VM上，当某个DB闲的时候，这
: 些资源就都使用在忙的的DB上了。换句话说VM的OS本身就可以根据DB的负载来分配资源。
: 两个VM实际上就强制限制了每个DB的可用资源，虽然可以通过改变VM的参数再调整，但
: 不是OS实时自动调整。
|
w***a
发帖数: 313 | 20 一点个人浅见，如果两个vm是基于同一个平台，共享存储cpu内存等硬件以及ESX，那么
对提供高可靠性帮助有限。平台挂了两个Vm同时没。单个vm自己出事的概率并不大。
把球踢给老板吧，问他最关心性能还是可用性。
【在 H*******d 的大作中提到】
: 问各位大牛一下哈：
: 公司的后台是建立在VM（Linux）上的，因为需要现在要把几个数据库（MySQL)合并成
: 两个。
: 合并后会只有两个数据库（webDB和nodeDB），一个是web访问的数据库（访问量没法预
: 测），一个是固定的节点访问的数据库（访问量根据节点的数量是计划过可计算的）。
: web端的appserver会同时访问到这两个数据库，而节点的appserver只会访问节点的数
: 据库
: 现在的的问题是怎么部署这两个数据库：
: 1.用两个不同的VM来host不同的数据库
: 优点：两台VM基本独立，即使一台挂了，另一个VM还可以正常运转。
|
