Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 10 reacties
Bron: MySQL

MySQL is een krachtige opensourcedatabaseserver die met name populair is als website- en forumdatabase. Ook Tweakers.net maakt gebruik van MySQL om onder andere gebruikersgegevens, statistieken en diverse review-, meuk- en nieuwsartikelen in op te slaan. De ontwikkelaars hebben een nieuwe ontwikkelingsversie de deur uitgedaan voor de meeste platformen en voorzien van een berg aanpassingen. Her versienummer is aanbeland bij 5.1.19 beta met de volgende lijst van aanpassingen:

Functionality added or changed:
  • INSERT DELAYED statements for BLACKHOLE tables caused a server crash. The BLACKHOLE storage engine now supports INSERT DELAYED. (Bug#27998)
  • The BLACKHOLE storage engine now supports LOCK TABLES and UNLOCK TABLES. (Bug#26241)
  • The data type used for the VARIABLE_VALUE column of the following INFORMATION_SCHEMA tables has been changed to VARCHAR:
    • GLOBAL_STATUS
    • SESSION_STATUS
    • GLOBAL_VARIABLES
    • SESSION_VARIABLES
    For more information, see Section 22.24, “The INFORMATION_SCHEMA GLOBAL_STATUS and SESSION_STATUS Tables”, Section 22.25, “The INFORMATION_SCHEMA GLOBAL_VARIABLES and SESSION_VARIABLES Tables”, and Bug#26994
Bugs fixed:
  • Security fix: Use of a view could allow a user to gain update privileges for tables in other databases. (Bug#27878)
  • Security fix: UDFs are supposed to be loadable only from the plugin directory, but this restriction was not being enforced. (Bug#28341)
  • NDB Cluster: When an API node sent more than 1024 signals in a single batch, NDB would process only the first 1024 of these, and then hang. (Bug#28443)
  • NDB Cluster (Disk Data): DDL operations were not supported on a partially started cluster. (Bug#24631)
  • NDB Cluster: A delay in obtaining AUTO_INCREMENT IDs could lead to excess temporary errors. (Bug#28410)
  • NDB Cluster: Local checkpoint files related to dropped NDB tables were not removed. (Bug#28348)
  • NDB Cluster: A failure to release internal resources following an error could lead to problems with single user mode. (Bug#25818)
  • NDB Cluster: Multiple operations involving deletes followed by reads were not handled correctly. (Bug#28276)
    Note: This issue could also affect MySQL Cluster Replication.
  • NDB Cluster (Disk Data): Extremely large inserts into Disk Data tables could lead to data node failure in some circumstances. (Bug#27942)
  • NDB Cluster: Repeated insertion of data generated by mysqldump into NDB tables could eventually lead to failure of the cluster. (Bug#27437)
  • NDB Cluster: Restarting a data node caused SQL nodes to log repeatedly and unnecessarily the status of the event buffer. (Bug#27292) (This issue was known to occur in MySQL 5.1.16 and later only.)
  • NDB Cluster: ndb_mgmd failed silently when the cluster configuration file contained invalid [TCP] entries. (Bug#27207)
  • NDB Cluster: ndb_connectstring did not appear in the output of SHOW VARIABLES. (Bug#26675)
  • NDB Cluster (APIs): In a multi-operation transaction, a delete operation followed by the insertion of an implicit NULL failed to overwrite an existing value. (Bug#20535)
  • Changing the size of a key buffer that is under heavy use could cause a server crash. The fix partially removes the limitation that LOAD INDEX INTO CACHE fails unless all indexes in a table have the same block size. Now the statement fails only if IGNORE LEAVES is specified. (Bug#17332)
  • EXPLAIN for a query on an empty table immediately after its creation could result in a server crash. (Bug#28272)
  • Grouping queries with correlated subqueries in WHERE conditions could produce incorrect results. (Bug#28337)
  • libmysql.dll could not be dynamically loaded on Windows. (Bug#28358)
  • Portability problems caused by use of isinf() were corrected. (Bug#28239)
  • Using a TEXT local variable in a stored routine in an expression such as SET var = SUBSTRING(var, 3) produced an incorrect result. (Bug#27415)
  • A large filesort could result in a division by zero error and a server crash. (Bug#27119)
  • The server could abort or deadlock for INSERT DELAYED statements for which another insert was performed implicitly (for example, via a stored function that inserted a row). (Bug#21483)
  • The server could hang for INSERT IGNORE ... ON DUPLICATE KEY UPDATE if an update failed. (Bug#28000)
  • Quoted labels in stored routines were mishandled, rendering the routines unusable. (Bug#21513)
  • Changes to some system variables should invalidate statements in the query cache, but invalidation did not happen. (Bug#27792)
  • Some ALTER TABLE statements that worked in MySQL 5.0 did not work in 5.1. (Bug#28415)
  • Flow control optimization in stored routines could cause exception handlers to never return or execute incorrect logic. (Bug#26977)
  • An attempt to execute CREATE TABLE ... SELECT when a temporary table with the same name already existed led to the insertion of data into the temporary table and creation of an empty non-temporary table. (Bug#24508)
  • Concurrent execution of CREATE TABLE ... SELECT and other statements involving the target table suffered from various race conditions, some of which might have led to deadlocks. (Bug#24738)
  • CREATE TABLE IF NOT EXISTS ... SELECT caused a server crash if the target table already existed and had a BEFORE INSERT trigger. (Bug#20903)
  • Deadlock occurred for attempts to execute CREATE TABLE IF NOT EXISTS ... SELECT when LOCK TABLES had been used to acquire a read lock on the target table. (Bug#20662)
  • It was not possible to use the value –9223372036854775808 (that is, –MAXVALUE + 1) when specifying a LIST partition. (Bug#28005)
  • Some InnoDB variables were missing from the output of mysqld --verbose --help. (Bug#26987)
  • CAST() to DECIMAL did not check for overflow. (Bug#27957)
  • Views ignored precision for CAST() operations. (Bug#27921)
  • For InnoDB, in some rare cases the optimizer preferred a more expensive ref access to a less expensive range access. (Bug#28189)
  • A query with a NOT IN subquery predicate could cause a crash when the left operand of the predicate evaluated to NULL. (Bug#28375)
  • Comparisons of DATE or DATETIME values for the IN() function could yield incorrect results. (Bug#28133)
  • LOAD DATA did not use CURRENT_TIMESTAMP as the default value for a TIMESTAMP column for which no value was provided. (Bug#27670)
Versienummer:5.1.19 beta
Besturingssystemen:Windows 9x, Windows NT, Windows 2000, Linux, BSD, Windows XP, macOS, Solaris, UNIX, Windows Server 2003, BeOS / ZetaOS, Windows Vista
Website:MySQL
Download:http://dev.mysql.com/downloads/mysql/5.1.html
Licentietype:Voorwaarden (GNU/BSD/etc.)
Moderatie-faq Wijzig weergave

Reacties (10)

Ik begin eerlijk gezegd, met alle gratis versies van de 'grote jongens' steeds meer te twijfelen aan het bestaansrecht van MySQL....

De gratis versies hebben meestal alleen een beperking in capaciteit en/of geheugengebruik, maar zijn verder volledig functioneel. Voor écht grote db's zal je toch niet met open-source gaan zitten rommelen, toch? (enkele enthousiatelingen daargelaten)
Ik zou niet weten waarom je niet Mysql zou kiezen, ik vind 't feit dat 't opensource bepaald geen tegenargument - zie bijv. andere projecten zoals PHP - deze zijn zeker groter dan concurrenten en draait ook vaak op zelfs de grootste websites.
MySQL heeft de welbekende lekken (doet SQL injection een belletje rinkelen?) en ik merk dat hoe groter de database, hoe slomer het systeem. Logisch natuurlijk, maar veel sneller dan bijvoorbeeld (mijn favoriet :P) PostgreSQL.
Eh... sinds wanneer is SQL injection een probleem van de database? Dat is toch echt een probleem dat de applicatie zelf moet oplossen (bijvoorbeeld in PHP met de PDO extensie).
Dat is een combinatie van de manier hoe de database werkt en de taal die er mee communiceert. SQL injection is een breed begrip (en MySQL kan best haar best doen om dit wat veiliger te maken: klik , klik en klik en hier op Tweakers: hup en hup. Meerendeel is oud nieuws en niet alles is SQL injection, maar toch zitten/zaten er wel wat lekken in).

Alleen krijg ik m'n reactie niet onder die van jou :o
Voor écht grote db's zal je toch niet met open-source gaan zitten rommelen, toch? (enkele enthousiatelingen daargelaten)
En behalve echt grote DBs zijn er geen DBs?
En ook echt grote bedrijven 'rommelen' met MySQL hoor
PostgreSQL is anders een 'grote jongen' en volledig open-source. Waarom zou je dan nog met beperkte gratis versies van commerciele bedrijven rommelen?
MySQL is al zo populair dat ik me niet kan voorstellen dat webhosters zomaar gaan switchen. Ik zou in ieder geval geen hostingpakket zonder MySQL database willen, al is het alleen maar om al die gratis software die ervoor geschreven is.
De grote database jongens doen niet kinderachtig over de prijzen van hun licenties. Voor websites kun je helaas niet volstaan met een 'seat' licentie, dus moet je de per processor licentie afnemen. Aangezien wij nu 4(*) dubbel (geen multi-core) processor databases hebben staan zouden wij dan 8 MS SQL 2000 Advanced Servers licenties van elke 20.000 dollar(!) moeten aanschaffen.
(*)Er zouden er oorspronkelijk 2 komen.

In plaats van een vermogen aan licenties te betalen hebben wij geinvesteerd in hardware.

Ter info: Onze database is 5TB groot en voert op een gemiddelde werkdag 5 miljoen transacties per dag uit. Een klein gedeelte (enkele tienduizenden) daarvan wordt door de website veroorzaakt, maar het over grote deel door 'achtergrond' processen.

MySQL heeft ook features welke de grote jongens (voor zover ik weet) niet hebben zoals een modulaire storage engine per tabel. Wij hebben zelfs als 'proof-of-concept' een imap-engine geschreven. Uiteraard mist MySQL ook een aantal features welke de 'grote' jongen wel hebben, maar hoe vaak worden die gebruikt.

Overigens hebben wij pas de keuze gemaakt voor MySQL toen er support voor stored procedures was toegevoegd. Daarvoor maakten wij gebruik van MS SQL 2000 (standard version (zonder clustering dus)).
Ik denk dat een belangrijk punt voor MySQL 5.1 is dat het disk-based clustering ondersteunt. In 5.0 heb je alleen memory-based clustering, wat betekend dat je je hele database in je geheugen moet laden (niet mogelijk dus bij hele grote databases)

Met MySQL 5.1 komen ze dus weer een stukje dichterbij de grote enterprise jongens.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True