MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Balasubramanian Kandasamy Date:February 1 2018 6:32pm
Subject:MySQL Cluster 7.6.4-dmr has been released
View as plain text  
Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

   - In-Memory storage - Real-time performance (with optional
     checkpointing to disk)
   - Transparent Auto-Sharding - Read & write scalability
   - Active-Active/Multi-Master geographic replication

   - 99.999% High Availability with no single point of failure
     and on-line maintenance
   - NoSQL and SQL APIs (including C++, Java, http, Memcached
     and JavaScript/Node.js)

MySQL Cluster 7.6.4-dmr, has been released and can be downloaded from

http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

http://www.mysql.com/products/cluster/

Enjoy !

Changes in MySQL NDB Cluster 7.6.4 (5.7.20-ndb-7.6.4) (2018-01-31,
Development Milestone 4)

    MySQL NDB Cluster 7.6.4 is a new release of NDB 7.6, based on
    MySQL Server 5.7 and including features in version 7.6 of the
    NDB storage engine, as well as fixing recently discovered
    bugs in previous NDB Cluster releases.

    Obtaining NDB Cluster 7.6.  NDB Cluster 7.6 source code and
    binaries can be obtained from
http://dev.mysql.com/downloads/cluster/.

    For an overview of changes made in NDB Cluster 7.6, see What
    is New in NDB Cluster 7.6
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-6.html).

    This release also incorporates all bug fixes and changes made
    in previous NDB Cluster releases, as well as all bug fixes
    and feature changes which were added in mainline MySQL 5.7
    through MySQL 5.7.20 (see Changes in MySQL 5.7.20
    (2017-10-16, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-20.html)).

      * Functionality Added or Changed

      * Bugs Fixed

    Functionality Added or Changed

      * Incompatible Change; NDB Disk Data: Due to changes in
        disk file formats, it is necessary to perform an
        --initial restart of each data node when upgrading
to or
        downgrading from this release.

      * Important Change; NDB Disk Data: NDB Cluster has improved
        node restart times and overall performance with
larger
        data sets by implementing partial local checkpoints.
        Prior to this release, an LCP always made a copy of
the
        entire database.
        NDB now supports LCPs that write individual records,
so
        it is no longer strictly necessary for an LCP to
write
        the entire database. Since, at recovery, it remains
        necessary to restore the database fully, the
strategy is
        to save one fourth of all records at each LCP, as
well as
        to write the records that have changed since the
last
        LCP.
        Two data node configuration parameters relating to
this
        change are introduced in this release:
EnablePartialLcp
        (default true, or enabled) enables partial LCPs.
When
        partial LCPs are enabled, RecoveryWork controls the
        percentage of space given over to LCPs; it increases
with
        the amount of work which must be performed on LCPs
during
        restarts as opposed to that performed during normal
        operations. Raising this value causes LCPs during
normal
        operations to require writing fewer records and so
        decreases the usual workload. Raising this value
also
        means that restarts can take longer.
        Important
        Upgrading disk data tables to NDB 7.6.4 or
downgrading
        them from this release requires an initial restart
of
        each data node. An initial node restart still
requires a
        complete LCP; a partial LCP is not used for this
purpose.
        This release also deprecates the data node
configuration
        parameters BackupDataBufferSize, BackupWriteSize,
and
        BackupMaxWriteSize; these are now subject to removal
in a
        future NDB Cluster release.

      * Important Change: Added the ndb_perror utility for
        obtaining information about NDB Cluster error codes.
This
        tool replaces perror --ndb; the --ndb option for
perror
        is now deprecated and raises a warning when used;
the
        option is subject to removal in a future NDB
release.
        See ndb_perror --- Obtain NDB error message
information
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-programs-ndb-perror.html),
        for more information. (Bug
        #81703, Bug #81704, Bug #23523869, Bug #23523926)
        References: See also: Bug #26966826, Bug #88086.

      * NDB Client Programs: NDB Cluster Auto-Installer node
        configuration parameters as supported in the UI and
        accompanying documentation were in some cases hard
coded
        to an arbitrary value, or were missing altogether.
        Configuration parameters, their default values, and
the
        documentation have been better aligned with those
found
        in release versions of the NDB Cluster software.
        One necessary addition to this task was implementing
the
        mechanism which the Auto-Installer now provides for
        setting parameters that take discrete values. For
        example, the value of the data node parameter
Arbitration
        must now be one of Default, Disabled, or
WaitExternal.
        The Auto-Installer also now gets and uses the amount
of
        disk space available to NDB on each host for
deriving
        reasonable default values for configuration
parameters
        which depend on this value.
        See The NDB Cluster Auto-Installer
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-auto.html),
        for more information.

      * NDB Client Programs: Secure connection support in the
        MySQL NDB Cluster Auto-Installer has been updated or
        improved in this release as follows:

           + Added a mechanism for setting
SSH membership on a
             per-host basis.

           + Updated the Paramiko Python
module to the most
             recent available
version (2.6.1).

           + Provided a place in the GUI for
encrypted private
             key passwords, and
discontinued use of hardcoded
             passwords.
        Related enhancements implemented in the current
release
        include the following:

           + Discontinued use of cookies as a
persistent store
             for NDB Cluster
configuration information; these
             were not secure and
came with a hard upper limit on
             storage. Now the
Auto-Installer uses an encrypted
             file for this purpose.

           + In order to secure data transfer
between the web
             browser front end and
the back end web server, the
             default communications
protocol has been switched
             from HTTP to HTTPS.
        See The NDB Cluster Auto-Installer
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-auto.html),
        for more information.

      * It is now possible to specify a set of cores to be used
        for I/O threads performing offline multithreaded
builds
        of ordered indexes, as opposed to normal I/O duties
such
        as file I/O, compression, or decompression.
"Offline" in
        this context refers to building of ordered indexes
        performed when the parent table is not being written
to;
        such building takes place when an NDB cluster
performs a
        node or system restart, or as part of restoring a
cluster
        from backup using ndb_restore --rebuild-indexes.
        In addition, the default behaviour for offline index
        build work is modified to use all cores available to
        ndbmtd, rather limiting itself to the core reserved
for
        the I/O thread. Doing so can improve restart and
restore
        times and performance, availability, and the user
        experience.
        This enhancement is implemented as follows:

          1. The default value for
BuildIndexThreads is changed
             from 0 to 128. This
means that offline ordered index
             builds are now
multithreaded by default.

          2. The default value for
TwoPassInitialNodeRestartCopy
             is changed from false
to true. This means that an
             initial node restart
first copies all data from a
             "live" node to one
that is starting---without
             creating any
indexes---builds ordered indexes
             offline, and then
again synchronizes its data with
             the live node, that
is, synchronizing twice and
             building indexes
offline between the two
             synchonizations. This
causes an initial node restart
             to behave more like
the normal restart of a node,
             and reduces the time
required for building indexes.

          3. A new thread type (idxbld) is defined
for the
             ThreadConfig
configuration parameter, to allow
             locking of offline
index build threads to specific
             CPUs.
        In addition, NDB now distinguishes the thread types
that
        are accessible to "ThreadConfig" by the following
two
        criteria:

          1. Whether the thread is an execution
thread. Threads
             of types main, ldm,
recv, rep, tc, and send are
             execution threads;
thread types io, watchdog, and
             idxbld are not.

          2. Whether the allocation of the thread
to a given task
             is permanent or
temporary. Currently all thread
             types except idxbld
are permanent.
        For additonal information, see the descriptions of
the
        parameters in the Manual. (Bug #25835748, Bug
#26928111)

      * Added the ODirectSyncFlag configuration parameter for
        data nodes. When enabled, the data node treats all
        completed filesystem writes to the redo log as
though
        they had been performed using fsync.
        Note
        This parameter has no effect if at least one of the
        following conditions is true:

           + ODirect is not enabled.

           + InitFragmentLogFiles is set to
SPARSE.
        (Bug #25428560)

      * Added the ndbinfo.error_messages table, which provides
        information about NDB Cluster errors, including
error
        codes, status types, brief descriptions, and
        classifications. This makes it possible to obtain
error
        information using SQL in the mysql client (or other
MySQL
        client program), like this:
mysql> SELECT * FROM ndbinfo.error_messages WHERE error_code='321';
+------------+----------------------+-----------------+---------------
-------+
| error_code | error_description    | error_status    |
error_classifi
cation |
+------------+----------------------+-----------------+---------------
-------+
|        321 | Invalid nodegroup id | Permanent error |
Application er
ror    |
+------------+----------------------+-----------------+---------------
-------+
1 row in set (0.00 sec)

        The query just shown provides equivalent information
to
        that obtained by issuing ndb_perror 321 or (now
        deprecated) perror --ndb 321 on the command line.
(Bug
        #86295, Bug #26048272)

      * When executing a scan as a pushed join, all instances of
        DBSPJ were involved in the execution of a single
query;
        some of these received multiple requests from the
same
        query. This situation is improved by enabling a
single
        SPJ request to handle a set of root fragments to be
        scanned, such that only a single SPJ request is sent
to
        each DBSPJ instance on each node and batch sizes are
        allocated per fragment, the multi-fragment scan can
        obtain a larger total batch size, allowing for some
        scheduling optimizations to be done within DBSPJ,
which
        can scan a single fragment at a time (giving it the
total
        batch size allocation), scan all fragments in
parallel
        using smaller sub-batches, or some combination of
the
        two.
        Since the effect of this change is generally to
require
        fewer SPJ requests and instances, performance of
        pushed-down joins should be improved in many cases.

      * As part of work ongoing to optimize bulk DDL performance
        by ndbmtd, it is now possible to obtain performance
        improvements by increasing the batch size for the
bulk
        data parts of DDL operations which process all of
the
        data in a fragment or set of fragments using a scan.
        Batch sizes are now made configurable for unique
index
        builds, foreign key builds, and online
reorganization, by
        setting the respective data node configuration
parameters
        listed here:

           + MaxFKBuildBatchSize: Maximum
scan batch size used
             for building foreign
keys.

           + MaxReorgBuildBatchSize: Maximum
scan batch size used
             for reorganization of
table partitions.

           + MaxUIBuildBatchSize: Maximum
scan batch size used
             for building unique
keys.
        For each of the parameters just listed, the default
value
        is 64, the minimum is 16, and the maximum is 512.
        Increasing the appropriate batch size or sizes can
help
        amortize inter-thread and inter-node latencies and
make
        use of more parallel resources (local and remote) to
help
        scale DDL performance.

      * Formerly, the data node LGMAN kernel block processed undo
        log records serially; now this is done in parallel.
The
        rep thread, which hands off undo records to local
data
        handler (LDM) threads, waited for an LDM to finish
        applying a record before fetching the next one; now
the
        rep thread no longer waits, but proceeds immediately
to
        the next record and LDM.
        There are no user-visible changes in functionality
        directly associated with this work; this performance
        enhancement is part of the work being done in NDB
7.6 to
        improve undo long handling for partial local
checkpoints.

      * When applying an undo log the table ID and fragment ID
        are obtained from the page ID. This was done by
reading
        the page from PGMAN using an extra PGMAN worker
thread,
        but when applying the undo log it was necessary to
read
        the page again.
        This became very inefficient when using O_DIRECT
(see
        ODirect) since the page was not cached in the OS
kernel.
        Mapping from page ID to table ID and fragment ID is
now
        done using information the extent header contains
about
        the table IDs and fragment IDs of the pages used in
a
        given extent. Since the extent pages are always
present
        in the page cache, no extra disk reads are required
to
        perform the mapping, and the information can be read
        using existing TSMAN data structures.

      * Added the NODELOG DEBUG command in the ndb_mgm client to
        provide runtime control over data node debug
logging.
        NODE DEBUG ON causes a data node to write extra
debugging
        information to its node log, the same as if the node
had
        been started with --verbose. NODELOG DEBUG OFF
disables
        the extra logging.

      * Added the LocationDomainId configuration parameter for
        management, data, and API nodes. When using NDB
Cluster
        in a cloud environment, you can set this parameter
to
        assign a node to a given availability domain or
        availability zone. This can improve performance in
the
        following ways:

           + If requested data is not found
on the same node,
             reads can be directed
to another node in the same
             availability domain.

           + Communication between nodes in
different
             availability domains
are guaranteed to use NDB
             transporters' WAN
support without any further manual
             intervention.

           + The transporter's group number
can be based on which
             availability domain is
used, such that also SQL and
             other API nodes
communicate with local data nodes in
             the same availability
domain whenever possible.

           + The arbitrator can be selected
from an availability
             domain in which no
data nodes are present, or, if no
             such availability
domain can be found, from a third
             availability domain.
        This parameter takes an integer value between 0 and
16,
        with 0 being the default; using 0 is the same as
leaving
        LocationDomainId unset.

    Bugs Fixed

      * Important Change: The --passwd option for ndb_top is now
        deprecated, and thus subject to removal in a future
        release of NDB Cluster. (Bug #88236, Bug #20733646)
        References: See also: Bug #86615, Bug #26236320.

      * 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)

      * NDB Disk Data: An ALTER TABLE that switched the table
        storage format between MEMORY and DISK was always
        performed in place for all columns. This is not
correct
        in the case of a column whose storage format is
inherited
        from the table; the column's storage type is not
changed.
        For example, this statement creates a table t1 whose
        column c2 uses in-memory storage since the table
does so
        implicitly:
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT) ENGINE NDB;

        The ALTER TABLE statement shown here is expected to
cause
        c2 to be stored on disk, but failed to do so:
ALTER TABLE t1 STORAGE DISK TABLESPACE ts1;

        Similarly, an on-disk column that inherited its
storage
        format from the table to which it belonged did not
have
        the format changed by ALTER TABLE ... STORAGE
MEMORY.
        These two cases are now performed as a copying
alter, and
        the storage format of the affected column is now
changed.
        (Bug #26764270)

      * NDB Replication: On an SQL node not being used for a
        replication channel with sql_log_bin=0 it was
possible
        after creating and populating an NDB table for a
table
        map event to be written to the binary log for the
created
        table with no corresponding row events. This led to
        problems when this log was later used by a slave
cluster
        replicating from the mysqld where this table was
created.
        Fixed this by adding support for maintaining a
cumulative
        any_value bitmap for global checkpoint event
operations
        that represents bits set consistently for all rows
of a
        specific table in a given epoch, and by adding a
check to
        determine whether all operations (rows) for a
specific
        table are all marked as NOLOGGING, to prevent the
        addition of this table to the Table_map held by the
        binlog injector.
        As part of this fix, the NDB API adds a new
        getNextEventOpInEpoch3() method which provides
        information about any AnyValue received by making it
        possible to retrieve the cumulative any_value
bitmap.
        (Bug #26333981)

      * ndbinfo Information Database: Counts of committed rows
        and committed operations per fragment used by some
tables
        in ndbinfo were taken from the DBACC block, but due
to
        the fact that commit signals can arrive out of
order,
        transient counter values could be negative. This
could
        happen if, for example, a transaction contained
several
        interleaved insert and delete operations on the same
row;
        in such cases, commit signals for delete operations
could
        arrive before those for the corresponding insert
        operations, leading to a failure in DBACC.
        This issue is fixed by using the counts of committed
rows
        which are kept in DBTUP, which do not have this
problem.
        (Bug #88087, Bug #26968613)

      * Errors in parsing NDB_TABLE modifiers could cause memory
        leaks. (Bug #26724559)

      * Added DUMP code 7027 to facilitate testing of issues
        relating to local checkpoints. For more information,
see
        DUMP 7027
(http://dev.mysql.com/doc/ndb-internals/en/ndb-internals-dump-command-7027.html).
        (Bug #26661468)

      * A previous fix intended to improve logging of node
        failure handling in the transaction coordinator
included
        logging of transactions that could occur in normal
        operation, which made the resulting logs needlessly
        verbose. Such normal transactions are no longer
written
        to the log in such cases. (Bug #26568782)
        References: This issue is a regression of: Bug
#26364729.

      * Due to a configuration file error, CPU locking capability
        was not available on builds for Linux platforms.
(Bug
        #26378589)

      * Some DUMP codes used for the LGMAN kernel block were
        incorrectly assigned numbers in the range used for
codes
        belonging to DBTUX. These have now been assigned
symbolic
        constants and numbers in the proper range (10001,
10002,
        and 10003). (Bug #26365433)

      * Node failure handling in the DBTC kernel block consists
        of a number of tasks which execute concurrently, and
all
        of which must complete before TC node failure
handling is
        complete. This fix extends logging coverage to
record
        when each task completes, and which tasks remain,
        includes the following improvements:

           + Handling interactions between
GCP and node failure
             handling interactions,
in which TC takeover causes
             GCP participant stall
at the master TC to allow it
             to extend the current
GCI with any transactions that
             were taken over; the
stall can begin and end in
             different GCP protocol
states. Logging coverage is
             extended to cover all
scenarios. Debug logging is
             now more consistent
and understandable to users.

           + Logging done by the QMGR block
as it monitors
             duration of node
failure handling duration is done
             more frequently. A
warning log is now generated
             every 30 seconds
(instead of 1 minute), and this now
             includes DBDIH block
debug information (formerly
             this was written
separately, and less often).

           + To reduce space used, DBTC
instance number: is
             shortened to DBTC
number:.

           + A new error code is added to
assist testing.
        (Bug #26364729)

      * During a restart, DBLQH loads redo log part metadata for
        each redo log part it manages, from one or more redo
log
        files. Since each file has a limited capacity for
        metadata, the number of files which must be
consulted
        depends on the size of the redo log part. These
files are
        opened, read, and closed sequentially, but the
closing of
        one file occurs concurrently with the opening of the
        next.
        In cases where closing of the file was slow, it was
        possible for more than 4 files per redo log part to
be
        open concurrently; since these files were opened
using
        the OM_WRITE_BUFFER option, more than 4 chunks of
write
        buffer were allocated per part in such cases. The
write
        buffer pool is not unlimited; if all redo log parts
were
        in a similar state, the pool was exhausted, causing
the
        data node to shut down.
        This issue is resolved by avoiding the use of
        OM_WRITE_BUFFER during metadata reload, so that any
        transient opening of more than 4 redo log files per
log
        file part no longer leads to failure of the data
node.
        (Bug #25965370)

      * A join entirely within the materialized part of a
        semi-join was not pushed even if it could have been.
In
        addition, EXPLAIN provided no information about why
the
        join was not pushed. (Bug #88224, Bug #27022925)
        References: See also: Bug #27067538.

      * When the duplicate weedout algorithm was used for
        evaluating a semi-join, the result had missing rows.
(Bug
        #88117, Bug #26984919)
        References: See also: Bug #87992, Bug #26926666.

      * A table used in a loose scan could be used as a child in
        a pushed join query, leading to possibly incorrect
        results. (Bug #87992, Bug #26926666)

      * When representing a materialized semi-join in the query
        plan, the MySQL Optimizer inserted extra QEP_TAB and
        JOIN_TAB objects to represent access to the
materialized
        subquery result. The join pushdown analyzer did not
        properly set up its internal data structures for
these,
        leaving them uninitialized instead. This meant that
later
        usage of any item objects referencing the
materialized
        semi-join accessed an initialized tableno column
when
        accessing a 64-bit tableno bitmask, possibly
referring to
        a point beyond its end, leading to an unplanned
shutdown
        of the SQL node. (Bug #87971, Bug #26919289)

      * In some cases, a SCAN_FRAGCONF signal was received after
        a SCAN_FRAGREQ with a close flag had already been
sent,
        clearing the timer. When this occurred, the next
        SCAN_FRAGREF to arrive caused time tracking to fail.
Now
        in such cases, a check for a cleared timer is
performed
        prior to processing the SCAN_FRAGREF message. (Bug
        #87942, Bug #26908347)

      * While deleting an element in Dbacc, or moving it during
        hash table expansion or reduction, the method used
        (getLastAndRemove()) could return a reference to a
        removed element on a released page, which could
later be
        referenced from the functions calling it. This was
due to
        a change brought about by the implementation of
dynamic
        index memory in NDB 7.6.2; previously, the page had
        always belonged to a single Dbacc instance, so
accessing
        it was safe. This was no longer the case following
the
        change; a page released in Dbacc could be placed
directly
        into the global page pool where any other thread
could
        then allocate it.
        Now we make sure that newly released pages in Dbacc
are
        kept within the current Dbacc instance and not given
over
        directly to the global page pool. In addition, the
        reference to a released page has been removed; the
        affected internal method now returns the last
element by
        value, rather than by reference. (Bug #87932, Bug
        #26906640)
        References: See also: Bug #87987, Bug #26925595.

      * The DBTC kernel block could receive a TCRELEASEREQ signal
        in a state for which it was unprepared. Now it such
cases
        it responds with a TCRELEASECONF message, and
        subsequently behaves just as if the API connection
had
        failed. (Bug #87838, Bug #26847666)
        References: See also: Bug #20981491.

      * When a data node was configured for locking threads to
        CPUs, it failed during startup with Failed to lock
tid.
        This was is a side effect of a fix for a previous
issue,
        which disabled CPU locking based on the version of
the
        available glibc. The specific glibc issue being
guarded
        against is encountered only in response to an
internal
        NDB API call (Ndb_UnlockCPU()) not used by data
nodes
        (and which can be accessed only through internal API
        calls). The current fix enables CPU locking for data
        nodes and disables it only for the relevant API
calls
        when an affected glibc version is used. (Bug #87683,
Bug
        #26758939)
        References: This issue is a regression of: Bug
#86892,
        Bug #26378589.

      * ndb_top failed to build on platforms where the ncurses
        library did not define stdscr. Now these platforms
        require the tinfo library to be included. (Bug
#87185,
        Bug #26524441)

      * On completion of a local checkpoint, every node sends a
        LCP_COMPLETE_REP signal to every other node in the
        cluster; a node does not consider the LCP complete
until
        it has been notified that all other nodes have sent
this
        signal. Due to a minor flaw in the LCP protocol, if
this
        message was delayed from another node other than the
        master, it was possible to start the next LCP before
one
        or more nodes had completed the one ongoing; this
caused
        problems with LCP_COMPLETE_REP signals from previous
LCPs
        becoming mixed up with such signals from the current
LCP,
        which in turn led to node failures.
        To fix this problem, we now ensure that the previous
LCP
        is complete before responding to any TCGETOPSIZEREQ
        signal initiating a new LCP. (Bug #87184, Bug
#26524096)

      * NDB Cluster did not compile successfully when the build
        used WITH_UNIT_TESTS=OFF. (Bug #86881, Bug
#26375985)

      * Recent improvements in local checkpoint handling that use
        OM_CREATE to open files did not work correctly on
Windows
        platforms, where the system tried to create a new
file
        and failed if it already existed. (Bug #86776, Bug
        #26321303)

      * A potential hundredfold signal fan-out when sending a
        START_FRAG_REQ signal could lead to a node failure
due to
        a job buffer full error in start phase 5 while
trying to
        perform a local checkpoint during a restart. (Bug
#86675,
        Bug #26263397)
        References: See also: Bug #26288247, Bug #26279522.

      * Compilation of NDB Cluster failed when using
        -DWITHOUT_SERVER=1 to build only the client
libraries.
        (Bug #85524, Bug #25741111)

      * The NDBFS block's OM_SYNC flag is intended to make sure
        that all FSWRITEREQ signals used for a given file
are
        synchronized, but was ignored by platforms that do
not
        support O_SYNC, meaning that this feature did not
behave
        properly on those platforms. Now the synchronization
flag
        is used on those platforms that do not support
O_SYNC.
        (Bug #76975, Bug #21049554)

On Behalf of Oracle/MySQL Release Engineering Team
Balasubramanian Kandasamy


Thread
MySQL Cluster 7.6.4-dmr has been releasedBalasubramanian Kandasamy1 Feb