这个版本已修复了很多bug,小鱼儿玄机30码姐妹一

2019-09-22 作者:数据库   |   浏览(159)

我们MySQL线上环境大部分使用的是5.7.18的版本,这个版本已修复了很多bug,但针对主从复制的bug还是有很多的,尤其是一些组复制、并行复制的bug尤为突出,在5.7.19版本有做相应改善和修复。所以建议5.7.19之前的版本还是不要使用mgr和并发复制的功能,如使用建议升级至5.7.19(含)以后的版本。

系列目录

ed2k://|file|cn_sql_server_2008_r2_enterprise_x86_x64_ia64_dvd_522233.iso|4662884352|1DB025218B01B48C6B76D6D88630F541|/

MySQL支持的数据类型很多,那么选择合适的数据类型对于获得高性能就至关重要。那么就先了解各种类型的优缺点!

我这里遇到的问题主要是莫名其妙的数据同步出现问题,无法执行stop slave,数据不一致等现象,经过查看发现是版本bug所致,所以对已上线的从库关闭并发复制,对未上线的系统实行版本升级。此风险非常非常高,各位务必重视。

一、安装MySql

一、类型介绍

具体5.7.19修复的复制bug如下:

二、安装并破解Navicat

1、整型类型

参考手册:

三、没有my.in配置文件怎么办

  整型类型有: TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT 。他们分别占8,16,24,32,64位储存空间。可存储的整数范围为-2^(N-1)到2^(N-1)-1,其中N是存储空间的位数。

References: See also: Bug #84107.

Replication: In the case of delayed initialization of the Group Replication plugin, deployed in single-primary mode, secondaries were able to get writes through an asynchronous replication channel, which is not allowed in normal initialization of the Group Replication plugin. (Bug #26314756)

Replication: With GTIDs generated for incident log events, MySQL error code 1590 (ER_SLAVE_INCIDENT) could not be skipped using the --slave-skip-errors=1590 startup option on a replication slave. (Bug #26266758)

Replication: A USE statement that followed a SET GTID_NEXT statement sometimes had no effect. (Bug #26128931)

Replication: Groups can now contain members running different server versions to enable you to do online upgrades of a replication group. The rules for combining members in a group with different versions are:

    If you have a group with 8.0 members, you cannot add a 5.7 member

    If you have a group with 5.7 members you can add a 8.0 member, but it remains in read-only mode. Writing to this member is dangerous while the group contains multiple server versions and should be avoided.

In a single-primary group, if the current primary leaves the group and a new primary must be elected, the primary is first chosen from the lower version members. If no lower version member is found, the primary is chosen from newer version members. (Bug #25876807)

Replication: When binlog_checksum=NONE was set on a MySQL server after startup, and then Group Replication was started, if an error occurred, the server remained in RECOVERING state and could not be shut down. (Bug #25793366, Bug #85667)

Replication: In a Group Replication setup where circular asynchronous replication was implemented between members of different replication groups, view change log events were repeatedly replicated between the groups with new generated GTIDs each time. The fix ensures that view change log events are ignored outside the named replication group where they occur, and never generate new GTIDs. (Bug #25674926)

References: See also: Bug #26049695, Bug #25928854, Bug #25721175.

Replication: When first starting the MySQL server following an installation from RPM, passwword validation plugin is activated by default (true only for RPM installations). If binary logging was already enabled at this time, the activation was logged, even though plugin activations should not be recorded in the binary log. (Bug #25672750)

Replication: In a setup where single-primary Group Replication was combined with asynchronous replication, for example with S1 and S2 forming a group and with S2 and S3 functioning as master and slave, secondaries such as S2 were accepting transactions and these could then enter the group. The fix prevents secondaries creating an asynchronous replication channel when belonging to a single-primary group, and Group Replication cannot be started when asynchronous replication is running. (Bug #25574200, Bug #85047)

References: See also: Bug #86325, Bug #26078602.

Replication: In the event that a member failed to join a group the member was not stopping and continued to accept transactions. To avoid this set your members to have super_read_only=1 in the my.cfg file. Group Replication now checks for this setting upon successful start up and sets super_read_only=0. This ensures that members which do not successfully join a group cannot accept transactions. (Bug #25474736, Bug #84728)

Replication: If the binary log on a master server was rotated and a full disk condition occurred on the partition where the binary log file was being stored, the server could stop unexpectedly. The fix adds a check for the existence of the binary log when the dump thread switches to next binary log file. If the binary log is disabled, all binary logs up to the current active log are transmitted to slave and an error is returned to the receiver thread. (Bug #25076007)

Replication: Interleaved transactions could sometimes deadlock the slave applier when the transaction isolation level was set to REPEATABLE-READ. (Bug #25040331)

Replication: If a relay log index file named relay log files that did not exist, RESET SLAVE ALL sometimes did not fully clean up properly. (Bug #24901077)

Replication: The slave_skip_errors system variable did not permit error numbers larger than 3000. Thanks to Tsubasa Tanaka for the patch. (Bug #24748639, Bug #83184)

Replication: mysqlbinlog, if invoked with the --raw option, does not flush the output file until the process terminates. But if also invoked with the --stop-never option, the process never terminates, thus nothing is ever written to the output file. Now the output is flushed after each event. (Bug #24609402)

Replication: A memory leak in mysqlbinlog was fixed. The leak happened when processing fake rotate events, or when using --raw and the destination log file could not be created. The leak only occurred when processing events from a remote server. Thanks to Laurynas Biveinis for his contribution to fixing this bug. (Bug #24323288, Bug #82283)

Replication: A slave server could lose events not yet applied when MASTER_AUTO_POSITION=0, both replication threads were stopped, and the applier delay was changed using CHANGE MASTER TO MASTER_DELAY=N. (Bug #23203678, Bug #81232)

References: See also: Bug #25340185, Bug #84375.

Replication: Transmission of large GCS messages could take so long the sender appeared to have died. (Bug #22671846)

Replication: Multithreaded slaves could not be configured with small queue sizes using slave_pending_jobs_size_max if they ever needed to process transactions larger than that size. Any packet larger than slave_pending_jobs_size_max was rejected with the error ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, even if the packet was smaller than the limit set by slave_max_allowed_packet.

With this fix, slave_pending_jobs_size_max becomes a soft limit rather than a hard limit. If the size of a packet exceeds slave_pending_jobs_size_max but is less than slave_max_allowed_packet, the transaction is held until all the slave workers have empty queues, and then processed. All subsequent transactions are held until the large transaction has been completed. The queue size for slave workers can therefore be limited while still allowing occasional larger transactions. (Bug #21280753, Bug #77406)

Replication: An incident event that broke replication was not written to the binary log with a GTID, so that it was not possible to skip the event using SET gtid_next=value. Instead, it was necessary to set the relay log file and relay log positions directly; this meant that, when autopositioning was enabled, it was necessary first to disable it, then to set the relay log file and position, and finally to re-enable autopositioning.

Now in such cases MySQL writes the incident event into the statement cache, so that a GTID is generated and written for it prior to flushing, and that the slave applier works with the change. Then users can skip the event using the SQL statement SET gtid_next=value, followed by BEGIN and COMMIT. (Bug #19594845)

Replication: In certain cases, the master could write to the binary log a last_committed value which was smaller than it should have been. This could cause the slave to execute in parallel transactions which should not have been, leading to inconsistencies or other errors. (Bug #84471, Bug #25379659)

Replication: When using group_replication_ip_whitelist=AUTOMATIC, IPs in the private network are permitted automatically, but some class C IP addresses were not being permitted correctly. (Bug #84329, Bug #25503458)

Replication: When an existing GTID_NEXT transaction was assigned a conflicting GTID by the server, Group Replication generated an assert upon detecting two transactions with same GTID. This was because Group Replication generates the GTID after conflict detection, which is later than with master/slave replication. The fix relaxes some conditions to only be called when commit is done and a message has been added to alert you when a GTID has already been used. (Bug #84153, Bug #25232042)

Replication: The replication applier thread returns Error 3002 ER_INCONSISTENT_ERROR when there is a difference between an expected error number and the actual error number. It is now possible to ignore this error by using 3002 with slave_skip_errors. (Bug #83186, Bug #24753281)

Replication: MySQL lost its GTID position following a restart when a dump from mysqldump had been used to load data.

To keep this problem from occurring, the mysql.gtid_executed table is now excluded automatically from dumps made by mysqldump. (Bug #82848, Bug #24590891)

References: See also: Bug #87455, Bug #26643180.

Replication: Corruption of relay logs for one channel in multi-source replication caused good channels not to be initalized during a server restart. In addition, when run with --skip-slave-start=false, the server also failed to start slave threads for those channels which were in good condition, despite the fact that it should have started the slave threads for all good channels.

Now, regardless of any errors on other channels, the server attempts to create and initialize channels that are in good condition, and starts slave threads for the good channels if --skip-slave-start is disabled. As part of this fix, START SLAVE and STOP SLAVE, which are intended to operate on all channels, are also modified such that they continue executing on all good channels even if they find bad channels among them. (Bug #82209, Bug #24285104)

Replication: The SQL thread was unable to GTID skip a partial transaction. (Bug #81119, Bug #25800025)

Debian client packages were missing information about conflicts with akonadi-backend-mysql packages. (Bug #26002288)

四、设置MySql的大小写敏感

还可以将整数类型设为 UNSIGNED ,这样几乎可以是其范围增大一倍。例如TINYINT范围是-128

 

五、重置MySql登陆密码

  • 127,而TINYINT UNSIGNED的范围是0-255。不过这两种只是在范围上有缺别,在存储空间和性能上都是一样的。

 

 

2、实数类型

之前说过,Windows操作系统中,我们安装Mysql有两个选择:一是下载MSI点击运行,利用windows系统安装程序的方法按部就班的来安装;二是下载ZIP,解压出来就能立即使用。

  对于实数类型,MySQL即支持精确类型(DECIMAL),也支持不精确类型(FLOAT,DOUBLE)。

在使用ZIP安装时,安装好之后默认是没有my.ini配置文件的:

  DECIMAL类型允许最多存储65位数字,因此它可以存储比BIGINT还大的数字。而且在MySQL5.0或更高版本中,MySQL服务器自身实现的DECIMAL的高精度计算。但相比较浮点类型,因为CPU直接支持原声浮点计算,所以浮点类型计算会更快。

小鱼儿玄机30码姐妹 1

  通常来说,浮点类型在存储相同的范围时,比DECIMAL使用更少的空间。FLOAT占用4个字节存储,DOUBLE占用8个字节存储,但相比FLOAT有更高的精度和更大的范围。浮点类型存储时在精度上会有各种各样的问题,例如当你只把一列设为FLOAT,而没有指定精度时,在存储1234567.33会变成1234570。

当我们想修改数据库的配置信息如 wait_timeout、interactive_timeout、max_connections 或大小写敏感时,却找不到my.ini 配置文件。

  DECIMAL所占的字节比较特殊。它是在小数点前后分别使用每4个字节存储9位数字。具体看mysql手册说法:

本文由小鱼儿玄机30码发布于数据库,转载请注明出处:这个版本已修复了很多bug,小鱼儿玄机30码姐妹一

关键词: 小鱼儿玄机30码