SQLite 支持复制吗？
在嵌入 SQLite3 并使用内存数据库的应用程序中，是否可以在应用程序的两个运行实例之间复制数据库？我可以使用复制所有数据库访问的自制协议手动完成此操作，但这似乎应该在数据库层内完成。
In an application which embeds SQLite3 and uses an in-memory database, is it possible to replicate the database between two running instances of the application? I could do this by hand with a homebrew protocol duplicating all my DB accesses, but it seems like something that should be done inside the DB layer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
暴力方法：向其发送“.dump”命令以创建数据的文本表示形式。将该数据读入第二个数据库。不确定你可以使用它。
如果您需要细粒度更新（将每个副本发送到另一个副本），请查看
sqlite3_update_hook但是你打算如何处理错误呢？例如，当 app2 中的数据库副本由于某种原因无法进行更新时会发生什么？
要解决此问题，请将数据库移至服务器进程并让两个应用程序与之通信。
Brute force approach: Send it the ".dump" command to create a text representation of the data. Read that data in into the second database. Not sure you can use that.
If you need a fine grained update (sending a copy of each upto the other copy), have a look at
sqlite3_update_hookBut how do you plan to handle errors? For example, what happens when the copy of the DB in app2 can't make an update for some reason?
To solve this, move the database to a server process and have the two apps talk to it.
开箱即用，不。
有少量第三方选项：
SQLite 同步： https://ampliapps.com/sqlite-sync/ 这个看起来很有吸引力，因为它可以复制到其他数据库以及 SQLite，并且不会修改 SQLite 引擎。我还没试过。
Litereplica：http://litereplica.io/ 仅一种方式。似乎已经存在了一些。
LiteSync：http://litesync.io/ 双向复制。相当新，但是是 Litereplica 的演变，因此可能比看起来更成熟。我已经尝试过一点，它似乎运行顺利，但开发人员正在查看一些错误。您必须使用开发人员修改的 SQLite 引擎，这似乎是一个令人担忧的依赖项。您也没有太多的控制权，例如，您不能在不重新打开数据库的情况下说立即复制。
Out of the box, no.
There are a small number of third-party options:
SQLite sync: https://ampliapps.com/sqlite-sync/ This one seems attractive because it can replicate to other databases as well as SQLite, and doesn't modify the SQLite engine. I haven't tried it yet.
Litereplica: http://litereplica.io/ One way only. Seems to have been around a bit.
LiteSync: http://litesync.io/ Two-way replication. Pretty new, but an evolution of Litereplica so probably more mature than it appears. I have tried this a bit and it does seem to work smoothly, with a few bugs which the developer is looking at. You have to use the developer's modified SQLite engine, which seems like a concerning dependency. You also don't get much control, e.g. you can't say replicate now without reopening the database.
Lsyncd - 实时同步（镜像）守护进程可能会在此处有用。它使用 rsync 在文件级别进行连续复制。
Lsyncd - Live Syncing (Mirror) Daemon may be of use here. It uses rsync to do continuous replication on the file level.
如果您想在内存数据库中进行复制，您需要查看 berkeley数据库（BDB）。然而BDB的数据模型是字符串-字符串字典，所以你失去了SQL的灵活性。另外它有一个三条款许可证，所以如果您的项目是商业项目，您需要获得许可证。
If you want replication in an in-memory database you need to look at berkeley DB (BDB). However the data model for BDB is string-string dictionary, so you loose the flexibility of SQL. plus it has a three clause license, so if your project is commercial you need to get licenses.
我们仍然没有原生支持，尽管我们在备份方面有一些改进，请查看 docs，但是我们还有更多第三方选项：欢迎Litestream，它的发布和开发方式与SQLite类似。
We still do not have native support, although we have some improvements in backup, check docs, but we have more third party options: welcome Litestream, which is published and developed in a similar way to SQLite.
不，不是，因为该项目的范围是一个简单的进程内数据库。但由于数据库只是一个文件，因此您可以基于纯文件复制操作、rsync 或类似操作编写自己的复制脚本。
如果您确实想要基于 SQLite 的客户端/服务器类型的 RDBMS，您可以查看 SQLiteDBMS。
No it doesn't because the project's scope is being a simple in-process database. But because the database is just a single file, you could write your own replication script based on plain file copy operations, rsync or something similar.
If you really want a SQLite based client/server type of RDBMS, you could take a look at SQLiteDBMS.
齐奏？不过，你能做的最好的事情就是热备份，因为 SQLite 数据库位于一个整体文件中。您无法在两个“实例”之间进行循环。热备还不错，你只需拿起另一个应用程序+数据库就可以了，没有太多麻烦，相比之下MySQL主从或主动-被动需要一些手动干预，这并不容易。 MySQL 复制传递 SQL，而不仅仅是像 unison/rsync 那样的差异。但只要齐心协力，你就拥有了主人。
Unison? Best you could do though was hot spare, because SQLite db in one monolithic file. You couldn't round-robin between the two "instances". Hot spare isn't bad, you simply pick up the other app+db without much fuss, compare to MySQL master-slave or active-passive where there is some manual intervention which is not easy. MySQL replication passes around SQL, not just diffs like unison/rsync. But with unison you have master-master.