如何有选择地导出 github 存储库的 mysql 数据

发布于 2024-12-04 04:48:00 字数 133 浏览 5 评论 0原文

我们是一个开源项目,希望通过 github 公共存储库协作编辑我们的网站。

关于将 mysql 数据导出到 github 的最佳解决方案的任何想法,因为 mysql 可以在其中保存一些敏感信息,以及我们如何对其中发生的更改进行版本控制?

We're an opensource project and would like to collaboratively edit our website through github public repo.

Any ideas on the best solution to export the mysql data to github, as mysql can hold some sensitive info in it, and how we can version the changes that happen in it ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

南城旧梦 2024-12-11 04:48:00

答案是您不在存储库中保存数据。
您可能想要保存您的 ddl,也许还有一些配置数据。但仅此而已。
如果您想对数据进行版本控制,还有其他选择。 GIT 不是其中之一

Answer is you don't hold data in the repo.
You may want to hold your ddl, and maybe some configuration data. But that's it.
If you want to version control your data, there are other options. GIT isn't one of them

喜爱纠缠 2024-12-11 04:48:00

看来 dbdeploy 就是您正在寻找的

It seems dbdeploy is what you are looking for

扶醉桌前 2024-12-11 04:48:00

使用“由 git 后端支持”的博客引擎,忘记 mysql,在 github.com 上提交,推拉,主宰!

这是最好的列表:

  1. http://jekyllrb.com/
  2. http://nestacms.com/
  3. http://cloudhead. io/toto
  4. https://github.com/colszowka/serious

以防万一,...一个简单的、由 Git 驱动的wiki 具有良好的 API 和本地前端。 :

Use a blog engine "backend-ed by git", forget about mysql, commit on github.com, push and pull, dominate !

Here it is a list of the best:

  1. http://jekyllrb.com/
  2. http://nestacms.com/
  3. http://cloudhead.io/toto
  4. https://github.com/colszowka/serious

and just in case, ... a simple, Git-powered wiki with a sweet API and local frontend. :

背叛残局 2024-12-11 04:48:00

假设您希望以这种方式处理少量数据,您可以使用 mysqldump 转储您希望保持同步的表,检查转储到 git 中,然后将其推回结帐时进入您的数据库。

编写一个 shell 脚本,其功能相当于:

mysqldump [options] database table1 table2 ... tableN > important_data.sql

创建或更新文件。将该文件签入 git ,当您的数据发生重大变化时,您可以执行以下操作:

mysql [options] database < important_data.sql

理想情况下,最后一个将位于 git post-receive 挂钩中,这样您就永远不会忘记应用您的更改。

这就是你可以做到的。我不确定你是否愿意这样做。它看起来很脆弱,尤其是。如果团队成员 1 对感兴趣的表进行一些费力的更改,而团队成员 2 也在做同样的事情。其中一个将首先签入他们的更改,最好的情况是你会遇到一些令人讨厌的合并问题。最糟糕的情况是其中一个丢失了所有更改。

您可以通过始终在 important_data.sql 文件中进行更改来缓解这些问题,但其难易程度取决于您的应用程序。如果您这样做,您将需要使用 mysqldump 选项,以便获得一个可读且可合并的文件。

Assuming that you have a small quantity of data that you wish to treat this way, you can use mysqldump to dump the tables that you wish to keep in sync, check that dump into git, and push it back into your database on checkout.

Write a shell script that does the equivalent of:

mysqldump [options] database table1 table2 ... tableN > important_data.sql

to create or update the file. Check that file into git and when your data changes in a significant way you can do:

mysql [options] database < important_data.sql

Ideally that last would be in a a git post-receive hook, so you'd never forget to apply your changes.

So that's how you could do it. I'm not sure you'd want to do it. It seems pretty brittle, esp. if Team Member 1 makes some laborious changes to the tables of interest while Team Member 2 is doing the same. One of them is going to check-in their changes first, and best case you'll have some nasty merge issues. Worst case is that one of them lose all their changes.

You could mitigate those issues by always making your changes in the important_data.sql file, but the ease or difficulty of that depend on your application. If you do this, you'll want to play around with the mysqldump options so you get a nice readable, and git-mergable file.

多情出卖 2024-12-11 04:48:00

您可以将每个表导出为单独的 SQL 文件。只有当表改变时才可以再次推送。

You can export each table as a separate SQL file. Only when a table is changed it can be pushed again.

那片花海 2024-12-11 04:48:00

如果您谈论的是配置,那么我建议使用 sql 转储或类似的方法按照 Ray Baxters 的回答为数据库添加种子。

既然您提到了 Drupal,我猜测数据涉及用户/内容。因此,您确实应该考虑拥有一个可供每个开发人员远程连接的数据库 - 即一个版本。这是因为对 mysql 表的并发修改将极其难以协调(例如,两个 user.id = 10 的新用户各自发表一个 post.id = 1、post.user_id = 10 等的新帖子)。

当然,使用 sql 转储(可能保存在版本控制中)来备份它可能是有意义的,以防万一您的开发人员意外删除了某些关键内容。

If you were talking about configuration then I'd recommend sql dumps or similar to seed the database as per Ray Baxters answer.

Since you've mentioned Drupal, I'm guessing the data concerns users/ content. As such you really ought to be looking at having a single database that each developer connects to remotely - i.e. one single version. This is because concurrent modifications to mysql tables will be extremely difficult to reconcile (e.g. two new users both with user.id = 10 each making a new post with post.id = 1, post.user_id = 10 etc).

It may make sense, of course, to back this up with an sql dump (potentially held in version control) in case one of your developers accidentally deletes something critical.

梦幻之岛 2024-12-11 04:48:00

如果您只想要部分转储,PHPMyAdmin 会这样做。运行您的 SELECT 语句,当它显示时,页面的底部将出现一个导出链接(顶部的链接用于整个表格)。

If you just want a partial dump, PHPMyAdmin will do that. Run your SELECT statement and when it's displayed there will be an export link at the bottom of the page(the one at the top does the whole table).

固执像三岁 2024-12-11 04:48:00

您可以对 mysqldump 文件进行版本控制,这些文件只是前面答案中所述的 sql 脚本。根据您的评论,您的主要兴趣似乎是让开发人员拥有本地环境的基础。

这是 Drupal 6 的优秀 ERD。我不知道您使用的是哪个版本的 Drupal,也不知道 v6 和 v7 之间这些核心表是否发生了更改,但您可以使用转储、phpMyAdmin 或其他任何方式进行检查您可以使用的工具来检查数据库结构。 Drupal ERD

基于 ERD, Drupal 安装可能出现问题的数据位于 users、user_roles 和 authmap 表中。有一种快速方法可以省略这些内容,但请务必记住,添加的内容将与添加它的用户有关系,并且如果用户表中没有与内容对应的行,Drupal 可能会出现问题已添加。

因此,要编写 mysqldump 脚本,您只需排除有问题的表,或者至少排除用户表。

mysqldump -u drupaldbuser --password=drupaluserpw 0-ignore-table=drupaldb.user drupaldb > drupaldb.sql

您需要创建一个模拟用户表,其中包含一堆具有已知名称/密码组合的测试用户,您只需转储和版本一次,但理想情况下,您希望有足够的用户表来匹配或超过您的真实 drupal 用户数量将会添加内容。这只是为了使权限关系匹配。

You can version mysqldump files which are simply sql scripts as stated in the prior answers. Based on your comments it seems that your primary interest is to allow the developers to have a basis for a local environment.

Here is an excellent ERD for Drupal 6. I don't know what version of Drupal you are using or if there have been changes to these core tables between v6 and v7, but you can check that using a dump, or phpMyAdmin or whatever other tool you have available to you that lets you inspect the database structure. Drupal ERD

Based on the ERD, the data that would be problematic for a Drupal installation is in the users, user_roles, and authmap tables. There is a quick way to omit those, although it's important to keep in mind that content that gets added will have relationships to the users that added it, and Drupal may have problems if there aren't rows in the user table that correspond to what has been added.

So to script the mysqldump, you would simply exclude the problem tables, or at very least the user table.

mysqldump -u drupaldbuser --password=drupaluserpw 0-ignore-table=drupaldb.user drupaldb > drupaldb.sql

You would need to create a mock user table with a bunch of test users with known name/password combinations that you would only need to dump and version once, but ideally you want enough of these to match or exceed the number of real drupal users you'll have that will be adding content. This is just to make the permissions relationships match up.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文