数据库

云数据库 MySQL（Cloud DB for MySQL）是让用户可以轻松在云端部署、使用 MySQL 数据库。通过云数据库 MySQL，你不但可以在几分钟内即可部署MySQL 数据库实例，而且可以弹性调整硬件容量的大小而无需停机。另外云数据库 MySQL 提供备份回档、监控、快速扩容、数据传输等数据库运维全套解决方案，简化了IT 运维工作。 对于承载核心业务的数据库，大家最关心的是它的高可用性。业界用 N 个9 来量化可用性，目前云数据库MySQL高可用版实例，可用性能够达到99.95%. 云数据库 MySQL高可用版实例采用一主一备或一主两备的高可用模式，也是基于数据复制模式，无共享存储，通过数据复制协议达到主机和备机数据一致性，并且提供宕机自动检测和故障自动转移，主备切换和故障迁移过程对用户透明，数据节点部署在强大硬件之上，底层存储使用本地 PCI-e SSD 硬盘，提供强大的 IO 性能。 Cloud for MySQL 也提供了异步、半同步、强同步三种复制方式。强同步复制方式能最大限度的保障主从数据的一致性。云数据库 MySQL 高可用版本的强同步复制采用一主两备的架构，仅需其中一台 Slave 成功执行即可返回，避免了单台 Slave 不可用影响 Master 上操作的问题，也提高了强同步复制集群的可用性。 另外，高可用版支持企业级的高可用特性，比如只读实例

目前阿里， 清华，163等镜像站的Mariadb都是5.5的，有些项目需要用到更新的版本，所以顺便安装一下10版本的，并记录过程 添加中科大的Mariadb 10.2.25 yum源，并yum安装 [mariadb] name = MariaDB baseurl = https://mirrors.ustc.edu.cn/mariadb/yum/10.2/centos7-amd64 gpgkey = https://mirrors.ustc.edu.cn/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck=1 # 需要重新生成yum 缓存，再安装 yum clean all yum makecache all # 安装mariadb客户端，服务端 yum install mariadb-server mariadb -y # 启动 systemctl start mariadb #启动 MariaDB systemctl enable mariadb #设置开机启动 初始化前注意 在确认 MariaDB 数据库软件程序安装完毕并成功启动后请不要立即使用。为了确保数据 库的安全性和正常运转，需要先对数据库程序进行初始化操作。这个初始化操作涉及下面 5 个 步骤。 ➢ 设置 root 管理员在数据库中的密码值(注意，该密码并非 root 管理员在系统中的密

受疫情影响，全国各学校的开学均被延期。为避免耽误学生的课业，教育部推出了“停课不停学”政策，鼓励师生积极开展线上教学模式。 赶考状元（上海亿山睦教育科技有限公司）为此积极响应政府号召，向湖北全省一年级到高三的学子免费开放教材的同步在线教学课程，后来进一步扩大至全国范围。这一公益活动获得了很大反响，网站用户注册量和浏览量超过平时数倍。 虽然活动从策划到上线总共只有4天时间，赶考网技术团队通过科学决策，及时精密的实施，完成了业务代码改造、架构评估、扩容升级、SQL优化等工作，期间也和UCloud UDB团队紧密合作，在其协助下实现了数据库的架构改造和扩容，很好地承接了QPS暴涨20倍的访问压力，圆满完成技术保障任务。 下面分享一些我们在此过程中的细节和思考，供有快速扩容需要的企业参考。 面临的业务痛点 公司自2005年成立一直专注于K12在线教育，此次疫情公益活动构想阶段，业务侧运用此前超过十年的互联网及线下教育经验，快速设计了有效可行的方案，在不少细节上下了功夫，例如加速审核通道，只需两步即可学习的易用性，面向家长推广的二维码等。 技术团队的任务则是提前预判后台流量的迅猛增长，未雨绸缪设计行之有效的预案，查漏补缺，切实保障活动顺利流畅运行。为此我们细致梳理了现有架构的薄弱点，并相应制定了精准有效的扩容方案。 由于我们原先的扩容是稳定慢节奏的，这次预见到了大量访问需求

近期在开发过程中，因为项目开发环境连接的mysql数据库是阿里云的数据库，而阿里云的数据库版本是5.6的。而测试环境的mysql是自己安装的5.7。因此在开发过程中有小伙伴不注意写了有关group by的sql语句。在开发环境中运行是正常的，而到了测试环境中就发现了异常。 原因分析：MySQL5.7版本默认设置了 mysql sql_mode = only_full_group_by 属性，导致报错。 其中ONLY_FULL_GROUP_BY就是造成这个错误的罪魁祸首了,对于group by聚合操作,如果在select中的列没有在group by中出现,那么这个SQL是不合法的,因为列不在group by从句中,所以设置了sql_mode=only_full_group_by的数据库,在使用group by时就会报错。 测试环境下载安装的是最新版的mysql5.7.x版本，默认是开启了 only_full_group_by 模式的，但开启这个模式后，原先的 group by 语句就报错，然后又把它移除了。 一旦开启 only_full_group_by ，感觉，group by 将变成和 distinct 一样，只能获取受到其影响的字段信息，无法和其他未受其影响的字段共存，这样，group by 的功能将变得十分狭窄了 only_full_group_by 模式开启比较好。因为在

并发控制 并发情况下，需要做一些控制（一般是加锁），保证共享数据的一致性。 并发操作数据库时，需要给数据库中的数据加锁，确保数据库中数据的一致性。 数据库锁的常见分类 按使用方式来分：悲观锁、乐观锁 按锁级别来分：共享锁、排它锁（主要是这2种，当然还有其他的） 按锁粒度来分：行级锁、表级锁、页级锁 悲观锁 Pessimistic Lock 悲观的，假设是最坏的情况，认为其它线程一定会修改当前线程使用的数据库数据，当前线程一定要给使用的数据库数据加锁。 悲观锁只是个统称，并不是指某一种具体的锁。悲观锁主要包括： 共享锁（S锁，share），又称为读锁，所有线程都可以访问，但都只能读 排它锁（X锁），又称为写锁，是排它的，同一时刻只能有一个线程来访问，这个线程可对加锁的数据进行读写。 Java中的 synchronized、 ReentrantLock 等独占锁就是悲观锁思想的实现。 悲观锁一般要借助数据库本身提供的锁机制来实现。 以mysql最常用的InnoDB引擎为例：加排它锁 begin; //开始事务 select * from tb_user where id=1 for update; //给选中的行加锁 update tb_user set username='chy',password='abcd' where id=1; //修改数据 commit; //提交事务

　　你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？ 　　一般来说，如果允许缓存可以稍微的跟数据库偶尔有不一致的情况，也就是说如果你的系统 不是严格要求 “缓存+数据库” 必须保持一致性的话，最好不要做这个方案，即： 读请求和写请求串行化 ，串到一个 内存队列 里去。 　　串行化可以保证一定不会出现不一致的情况，但是它也会导致系统的吞吐量大幅度降低，用比正常情况下多几倍的机器去支撑线上的一个请求。 一、Cache Aside Pattern 最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。 更新的时候 ， 先删除缓存，然后更新数据库 。 为什么是删除缓存，而不是更新缓存？ 　　原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。 　　另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于 比较复杂的缓存数据计算的场景 ，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新

何谓悲观锁与乐观锁 乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。 悲观锁 总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。 乐观锁 总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。 两种锁的使用场景 从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候

存带微信表情的昵称 原因：utf-8编码可能2个字节、3个字节、4个字节的字符，但是MySQL的utf8编码只支持3字节的数据，而移动端的表情数据是4个字节的字符。如果直接往采用utf-8编码的数据库中插入表情数据，程序中将报SQL异常。 前提：mysql支持utf8mb4的版本不低于5.5.3，mysql驱动版本不能低于5.1.13。若不是，升级到最新版本。 在一次微信开发中，出现了用户无法注册的问题，后来排查发现，是用户的昵称中带有表情，无法存进mysql数据库（mysql使用的是utf-8编码）。 在网上查询有以下几种解决方案： 1、把昵称在保存进数据库前，进行编码转换。 2、（1）把数据库中昵称的字段改为utf8mb4 （2）把tp5的数据库配置文件中的数据库默认编码（charset），有utf-8改为 utf8mb4。 3、过滤特殊表情符号 三种方法都可以解决 来源： https://www.cnblogs.com/zwtqf/p/11305965.html

数据库管理员DBA什么是DBA 　　 数据库管理员，英文是Database Administrator，简称DBA。这个职位对不同的人意味着不同的意义。一个小的软件开发工作室和一个分工高度明细的大公司相比，DBA的职责来得更加宽泛一些。一个公司，不管它是自己开发应用软件，还是购买第三方的应用软件，只要涉及到数据库（有多少不涉及数据库的应用软件呢？数据库是商业的灵魂和大脑啊），就需要确定是否雇佣一个或几个DBA。知道DBA这个职位有哪些要求，对于企业内部这个职位的定义或者对于那些未来的DBA将是至关重要的。 DBA的一些职责： 安装和升级数据库服务器（如Oracle、Microsoft SQL server），以及应用程序工具。 数据库设计系统存储方案，并制定未来的存储需求计划。 一旦开发人员设计了一个应用，就需要DBA来创建数据库存储结构（tablespaces）。 一旦开发人员设计了一个应用，就需要DBA来创建数据库对象（tables,views,indexes）。 根据开发人员的反馈信息，必要的时候，修改数据库的结构。 登记数据库的用户，维护数据库的安全性。 保证数据库的使用符合知识产权相关法规。 控制和监控用户对数据库的存取访问。 监控和优化数据库的性能。 制定数据库备份计划，灾难出现时对数据库信息进行恢复 维护适当介质上的存档或者备份数据 备份和恢复数据库

(PID 25556，线程 67)任务 Get-MailboxDatabase 正在引发未处理的异常: System.NullReferenceException: 未将对象引用设置到对象的实例。 在 Microsoft.Exchange.Management.SystemConfigurationTasks.GetDatabaseTask 1.WriteResult[T](IEnumerable 1 dataObjects) 在 Microsoft.Exchange.Configuration.Tasks.GetTaskBase 1.InternalProce***ecord()<br/>在 Microsoft.Exchange.Configuration.Tasks.GetObjectWithIdentityTaskBase 2.InternalProce***ecord() 在 Microsoft.Exchange.Management.SystemConfigurationTasks.GetDatabaseTask`1.InternalProce***ecord() 在 Microsoft.Exchange.Configuration.Tasks.Task.Proce***ecord()。 来源： 51CTO 作者： 胡志冲 链接： https://blog.51cto