看到网上一片文章说：数据库不适合Docker及容器化？

Question

文章连接
刚开始用docker，有点疑惑？

Answer 1

Concernant la base de données ne pouvant pas être placée dans Docker, il y a deux articles tordus, l'un est posté par l'auteur original, et le second est cet article, traduit

.

Toujours le même point de vue :

Lorsque le volume est petit, vous pouvez le faire avec désinvolture. Lorsque le volume est important, certaines choses ne fonctionneront pas. Les bases de données traditionnelles et le docker ne sont pas la bonne méthode. Il est recommandé de ne pas les conteneuriser directement. la base de données, vous avez besoin de la prise en charge de divers systèmes, notamment des systèmes middleware et des systèmes conteneurisés.

Si votre base de données peut automatiquement évoluer, effectuer une reprise après sinistre, changer et est livrée avec sa propre solution multi-nœuds, Docker est une meilleure solution.

Mais sinon, n’utilisez pas Docker.

Le texte original est également très clair :

在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。

---

Lorsque le trafic est faible, tout peut être conteneurisé. Base de données, application, hadoop, divers nœuds, nginx.

---

Lorsque le volume est important, les services liés au stockage ne sont pas adaptés à la conteneurisation. Les services sans état tels que la couche application et la couche métier conviennent à la conteneurisation. Les services gourmands en mémoire tels que la mise en cache peuvent être conteneurisés.

Pour faire simple, il y a trois problèmes : la reprise après sinistre, les performances et la cohérence des données.

En ce qui concerne les bases de données traditionnelles comme MySQL, il y a tellement de problèmes que je peux énumérer :

1. Comment conteneuriser MySQL ?

2. Que dois-je faire si la base de données principale mysqld s'agenouille ?

3. Que dois-je faire si le dockerd de la bibliothèque principale s'agenouille ?

4. Que dois-je faire si l'esclave mysqld s'agenouille ?

5. Que dois-je faire si le docker esclave s'agenouille ?

6. Mysql peut-il être rapidement étendu via des conteneurs lorsque le pic approche ? plan?

7. Solution de commutation maître-esclave de données ? Comment assurer la cohérence ?

8. Le volume pendant les périodes de pointe est suffisamment important, et parfois la capacité d'une machine physique n'est suffisante que pour un seul processus MySQL.

9. Donc c'est aussi une seule machine, pourquoi mysql ne peut-il pas être démarré directement ?

10. Pourquoi devons-nous mettre un conteneur à l'extérieur ? Quelle est la perte de performance ?

11. Comment mettre à jour MySQL ?

12. Le volume de données perdra-t-il des données ? (J'ai rencontré plusieurs fois des conteneurs endommagés...)

Mais MySQL n'est pas complètement incontenable.
Les entreprises qui ne sont pas sensibles à la perte de données (comme les produits trouvés par la recherche JD.com) peuvent être numérisées et utiliser le partage de base de données pour augmenter le débit en augmentant le nombre d'instances.

En ce qui concerne les problèmes mentionnés dans l'article original, certaines choses ont des défauts, mais elles sont bien pensées. Par exemple, la question suivante est très problématique (à propos des répertoires de données partagés) :

容易水平伸缩？是否要在多个实例之间共享数据目录？你不害怕直接数据并发问题和可能的数据损坏吗？使用专用数据环境部署多个实例不会更安全吗？最后搞一个主从复制？

En ce qui concerne les bases de données avec lesquelles j'ai été en contact jusqu'à présent, seules les bases de données telles que cassandra (il existe également tidb et cockroachdb, mais je n'ai pas encore rencontré de cas d'utilisation dans les grandes entreprises) sont adaptées à la conteneurisation.

Mais Cassandra elle-même est également sur le point d'être apatride : elle fournit ses propres solutions de reprise après sinistre, d'extension de capacité et de commutation.

---

Ce qui suit est une mention de JD.com.

JD.com est une valeur aberrante, mais JD.com a également mentionné des problèmes similaires et des éléments qui nécessitent une attention particulière.

计算类应用、无状态应用优先，例如微服务特别容易迁移到弹性云。
应用迁移到弹性云，最好选择统一的规格，避免各个实例的负载不均衡。
应用从物理机迁移到弹性云后，实例数量会增加，相应对后端服务的连接数会增加，特别是数据库连接，所以需要防止连接过载。
在弹性云上共享磁盘IO，要避免应用刷日志，减少本地读写文件，采用JFS或JIMDB来满足文件存储或共享数据需求。
容器的CPU核数原低于原有物理机的核数，应用需要根据CPU核数来合理地配置线程数和网络参数。
修改底层，让应用在运行时能准确地拿到自身容器的核数。

Même de nombreuses personnalisations ont été apportées à Docker.

Vous pouvez consulter le partage JD.com.

Answer 2

Pas adapté, pas incapable

S'il n'y a aucun problème avec une seule machine, cela est toujours bénéfique dans certains cas. Par exemple, lorsque la base de données Oracle de mon entreprise ajustait les paramètres auparavant, la base de données s'est écrasée et n'a pas pu être démarrée. Heureusement, j'utilisais Docker. cette fois-là, je l'ai donc exécuté directement. Pointez simplement le répertoire de données vers celui d'origine

.

Peu importe la façon dont vous créez un cluster, il n'est pas facile de le configurer manuellement à l'aide de docker ou d'outils comme swarm. Il est préférable de le construire directement sur une machine physique pour éviter les ennuis

.

Il existe une entreprise à l'étranger spécialisée dans les solutions de stockage de données pour les dockers, par exemple, flocker et rancher's convoy

.

Answer 3

Docker est plus adapté aux apatrides et ne changera pas le service.

S'il y a un grand nombre de clusters :
Écrivez le fichier docker. Ensuite, lorsque le code est téléchargé dans l'entrepôt de code, après avoir déployé le fichier docker, laissez le script de publication créer le service docker par lots et y insérer le code du service.

Non seulement MySQL, mais similaire à Redis et mc ne sont pas adaptés à l'installation dans Docker. En d'autres termes, mettre la base de données dans Docker est juste pour le plaisir d'utiliser Docker, et il n'y a pas beaucoup d'avantages.

Answer 4

Oui, car les caractéristiques de Docker déterminent qu'il n'est pas adapté au stockage de données. Non seulement les bases de données, mais également tous les services liés au stockage ne sont pas adaptés à l'utilisation de Docker.

Answer 5

Je n'arrive même pas à comprendre dans quel répertoire l'image mysql officielle stocke les données.